Page History

...

Available as of Camel 2.14

The metrics: component component allows to collect various metrics directly from Camel routes. Supported metric types are counter, histogram, meter and timer. Metrics provides simple way to measure behaviour behavior of application. Configurable reporting backend is enabling different integration options for collecting and visualizing statistics. The

The metrics component also provides a MetricsRoutePolicyFactory which that allows to expose route statistics to be exposed using codehale Codahale metrics, see . See bottom of page for details.

Maven users will need to add the following dependency to their pom.xml for this component:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-metrics</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>

URI

...

Format

metrics:[ meter | counter | histogram | timer ]:metricname[?options]

...

Camel Metrics Component uses by default MetricRegistry with Slf4jReporter and 60 second reporting interval. Default registry can be replaced with custom one by providing bean with name metricRegistry in Camel registry. 

For example using Spring Java Configuration.:

@Configuration
public static class MyConfig extends SingleRouteCamelConfiguration {

    @Bean
    @Override
    public RouteBuilder route() {
        return new RouteBuilder() {
            @Override
            public void configure() throws Exception {
                // define Camel routes here
            }
        };
    }

    @Bean(name = MetricsComponent.METRIC_REGISTRY_NAME)
    public MetricRegistry getMetricRegistry() {
        MetricRegistry registry = ...;
        return registry;
    }
}

Usage

Each metric has type and name. Supported types are counter, histogram, meter and timer. Metric name is simple string. If metric type is not provided then type meter is used by default.

...

Metric name defined in URI can be overridden by using header with name CamelMetricsName.

For example

from("direct:in")
    .setHeader(MetricsConstants.HEADER_METRIC_NAME, constant("new.name"))
    .to("metrics:counter:name.not.used")
    .to("direct:out");

will update counter with name new.name instead of name.not.used.

All Metrics All metrics specific headers are removed from the message once Metrics endpoint finishes processing of exchange. While processing exchange Metrics endpoint will catch all exceptions and write log entry using the exchange metrics endpoint any exceptions thrown are caught and written to as a log entry at level warn.

Anchor
counter counter

Metrics

...

Type Counter

metrics:counter:metricname[?options]

Options

If neither increment or decrement is defined then counter value will be incremented by one. If increment and decrement are both defined only only increment operation is called. 

// update counter simple.counter by 7
from("direct:in")
    .to("metric:counter:simple.counter?increment=7")
    .to("direct:out");

...

Message headers can be used to override increment and decrement values specified in Metrics the metrics component URI.

// update counter simple.counter by 417
from("direct:in")
    .setHeader(MetricsConstants.HEADER_COUNTER_INCREMENT, constant(417L))
    .to("metric:counter:simple.counter?increment=7")
    .to("direct:out");

...

Options

If no value is not set nothing is added to histogram and warning is logged.

...

Message header can be used to override value specified in Metrics metrics component URI.

// addsAdds value 992 to simple.histogram
from("direct:in")
    .setHeader(MetricsConstants.HEADER_HISTOGRAM_VALUE, constant(992L))
    .to("metric:histogram:simple.histogram?value=700")
    .to("direct:out")

...

Options

If mark is not set then meter.mark() is called without argument.

...

Message header can be used to override mark value specified in Metrics in metrics component URI.

// updates meter simple.meter with value 345
from("direct:in")
    .setHeader(MetricsConstants.HEADER_METER_MARK, constant(345L))
    .to("metric:meter:simple.meter?mark=123")
    .to("direct:out");

...

Options

If no action or invalid value is provided then warning is logged without any timer update. If action start is called on already running timer or stop is called on not running timer then nothing is updated and warning is logged.

// measure time taken by route "calculate"
from("direct:in")
    .to("metrics:timer:simple.timer?action=start")
    .to("direct:calculate")
    .to("metrics:timer:simple.timer?action=stop");

TimerContext objects are stored as as Exchange properties between different Metrics different metrics component calls.

Headers

Message header can be used to override action value specified in Metrics in metrics component URI.

// sets timer action using header
from("direct:in")
    .setHeader(MetricsConstants.HEADER_TIMER_ACTION, TimerAction.start)
    .to("metric:timer:simple.timer")
    .to("direct:out");

MetricsRoutePolicyFactory

This factory allows to add a RoutePolicy for each route which exposes route utilization statistics using codehale CodaHale metrics. This factory can be used in Java and XML as the examples below demonstrates. 

From Java you just add the factory to the CamelContext as shown below:

context.addRoutePolicyFactory(new MetricsRoutePolicyFactory());

And from XML DSL you define a a <bean> as follows:

  <!-- use camel-metrics route policy to gather metrics for all routes -->
  <bean id="metricsRoutePolicyFactory" class="org.apache.camel.component.metrics.routepolicy.MetricsRoutePolicyFactory"/>

The MetricsRoutePolicyFactory and MetricsRoutePolicy supports the following options:

From In Java code tou you can get hold of the com.codahale.metrics.MetricRegistry from the org.apache.camel.component.metrics.routepolicy.MetricsRegistryService as shown below:

MetricRegistryService registryService = context.hasService(MetricsRegistryService.class);

if (registryService != null) {
  MetricsRegistry registry = registryService.getMetricsRegistry();
  // ...
}

MetricsMessageHistoryFactory

Available as of Camel 2.17

This factory allows to use metrics to capture Message History performance statistics while routing messages. It works by using a metrics Timer for each node in all the routes. This factory can be used in Java and XML as the examples below demonstrates. 

From In Java you just set the factory to on the CamelContext as shown below:

context.setMessageHistoryFactory(new MetricsMessageHistoryFactory());

And from XML DSL you define a a <bean> as follows:

  <!-- use camel-metrics message history to gather metrics for all messages being routed -->
  <bean id="metricsMessageHistoryFactory" class="org.apache.camel.component.metrics.messagehistory.MetricsMessageHistoryFactory"/>

The following options is supported on the factory:

At runtime the metrics can be accessed from Java API or JMX which allows to gather the data as json JSON output.

From Java code you can do In Java, get the service from the CamelContext as shown:

MetricsMessageHistoryService service = context.hasService(MetricsMessageHistoryService.class);
String json = service.dumpStatisticsAsJson();

And the JMX API the MBean is registered in the type=services tree with name=MetricsMessageHistoryService.