Metrics Component

Available as of Camel 2.14

The metrics: 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 of application. Configurable reporting backend is enabling different integration options for collecting and visualizing statistics. The component also provides a MetricsRoutePolicyFactory which allows to expose route statistics using codehale metrics, see bottom of page for details.

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

+

Metrics Component

Available as of Camel 2.14

The metrics: 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 behavior of application. Configurable reporting backend is enabling different integration options for collecting and visualizing statistics.

The metrics component also provides a MetricsRoutePolicyFacto ry that allows route statistics to be exposed using Codahale metrics. See bottom of page for details.

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

-

URI format

+

URI Format

-

Metric Registry

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.

+

Metric Registry

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:

-

MetricRegistry uses internal thread(s) for reporting. There is no public API in DropWizard version 3.0.1 for users to clean up on exit. Thus using Camel Metrics Component leads to Java classloader leak and my cause OutOfMemoryErrors in some cases.

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.

Headers

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

For example

+

MetricRegistry uses internal thread(s) for reporting. There is no public API in DropWizard version 3.0.1 for users to clean up on exit. Thus using Camel Metrics Component leads to Java classloader leak and my cause OutOfMemoryErrors in some cases.

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 us ed by default.

Headers

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

For example

-

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

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 level warn.

Metrics type counter

+

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

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

Metrics Type Counter

-

Options

Name	Default	Description
increment	-	Long value to add to the counter
decrement	-	Long value to subtract from the counter

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

+

Options

Name	Default	Description
`increment`	`-`	Long value to add to the counter
`decrement`	`-`	Long value to subtract from the counter

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

-

Headers

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

+

Headers

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

Name	Description	Expected type
CamelMetricsCounterIncrement	Override increment value in URI	Long
CamelMetricsCounterDecrement	Override decrement value in URI	Long

Name	Description	Expected type
`CamelMetricsCounterIncrement`	Override increment value in URI	`Long`
`CamelMetricsCounterDecrement`	Override de crement value in URI	`Long`

Metric type histogram

-

Options

Name	Default	Description
value	-	Value to use in histogram

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

+

Options

Name	Default	Description
`value`	`-`	Value to use in histogram

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

-

Headers

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

Name	Description	Expected type
CamelMetricsHistogramValue	Override histogram value in URI	Long

-

Metric type meter

-

Options

Name	Default	Description
mark	-	Long value to use as mark

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

+

Options

Name	Default	Description
`mark`	`-`	Long value to use as mark

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

-

Headers

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

Name	Description	Expected type
CamelMetricsMeterMark	Override mark value in URI	Long

+

Headers

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

Name	Description	Expected type
`CamelMetricsMeterMark`	Override mark value in URI	`Long`

Metrics type timer

-

Options

Name	Default	Description
action	-	start or stop

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.

+

Options

Name	Default	Description
`action`	`-`	start or stop

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.

-

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

Headers

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

Name	Description	Expected type
CamelMetricsTimerAction	Override timer action in URI	`org.apache.camel.component.metrics.timer.TimerEndpoint.TimerAction`

+

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

Headers

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

Name	Description	Expected type
`CamelMetricsTimerAction`	Override timer action in URI	`org.apache.camel.component.metrics.timer.TimerEndpoint.TimerAction`

-

MetricsRoutePolicyFactory

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

Instead of using the MetricsRoutePolicyFactory you can define a MetricsRoutePolicy per route you want to instrument, in case you only want to instrument a few selected routes.

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

+

`MetricsRoutePolicyFactory`

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

Instead of using the MetricsRoutePolicyFactory you can define a MetricsRoutePolicy per route you want to instrument, in case you only want to instrument a few selected routes.

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

-

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

+

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

-

The MetricsRoutePolicyFactory and MetricsRoutePolicy supports the following options:

Name	Default	Description
useJmx	false	Whether to report fine grained statistics to JMX by using the `com.codahale.metrics.JmxReporter`. Notice that if JMX is enabled on CamelContext then a `MetricsRegistryService` mbean is enlisted under the services type in the JMX tree. That mbean has a single operation to output the statistics using json. Setting `useJmx` to true is onl y needed if you want fine grained mbeans per statistics type.
jmxDomain	org.apache.camel.metrics	The JMX domain name
prettyPrint	false	Whether to use pretty print when outputting statistics in json format
metricsRegistry		Allow to use a shared `com.codahale.metrics.MetricRegistry`. If none is provided then Camel will create a shared instance used by the this CamelContext.
rateUnit	TimeUnit.SECONDS	The unit to use for rate in the metrics reporter or when dumping the statistics as json.
durationUnit	TimeUnit.MILLISECONDS	The unit to use for duration in the metrics reporter or when dumping the statistics as json.
namePattern	##name##.##routeId##.##type##	Camel 2.17: The name pattern to use. Uses dot as separators, but you can change that. The values ##name##, ##routeId##, and ##type## will be replaced with actual value. Where ###name### is the name of the CamelContext. ###routeId### is the name of the route. And ###type### is the value of re sponses.

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

+

The MetricsRoutePolicyFactory and MetricsRoutePolicy supports the following options:

Name	Default	Description
`useJmx`	`false`	Whether to report fine grained statistics to JMX by using the `com.codahale.metrics.JmxReporter`. Notice that if JMX is enabled on CamelContext then a `MetricsRegistryService` mbean is enlisted under the services type in the JMX tree. That MBean has a si ngle operation to output the statistics using JSON. Setting `useJmx` to true is only needed if you want fine grained MBeans per statistics type.
`jmxDomain`	`org.apache.camel.metrics`	The JMX domain name.
`prettyPrint`	`false`	Whether to use pretty print when outputting statistics in JSON format.
`metricsRegistry`		Allow to use a shared `com.codahale.metrics.MetricRegistry` . If one is not configured Camel will create a shared instance for use by the `CamelContext`.
`rateUnit`	`TimeUnit.SECONDS`	The unit to use for rate in the metrics reporter or when dumping the statistics as JSON.
`durationUnit`	`TimeUnit.MILLISECONDS`	The unit to use for duration in the metrics reporter or when dumping the statistics as JSON.
`namePattern`	`##name##.##routeId##.##type##`	Camel 2.17: The name pattern to use. Uses dot as separators, but you can change that. The values `##name##`, `##routeId##`, and `##type##` will be replaced with actual value. Where `###name###` is the name of the `CamelContext. ###routeId###` is the id of the route, where `###type###` is the value of responses.

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

-

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 Java you just set the factory to the CamelContext as shown below:

+

`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.

In Java set the factory on the CamelContext as shown below:

-

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

+

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

-

The following options is supported on the factory:

Name	Default	Description
useJmx	false	Whether to report fine grained statistics to JMX by using the `com.codahale.metrics.JmxReporter`. Notice that if JMX is enabled on CamelContext then a `MetricsRegistryService` mbean is enlisted under the services type in the JMX tree. That mbean has a single operation to output the statistics using json. Setting `useJmx` to true is only needed if you want fine grained mbeans per statistics type.
jmxDomain	org.apache.camel.metrics	The JMX domain name
prettyPrint	false	Whether to use pretty print when outputting statistics in json format
metricsRegistry		Allow to use a shared `com.codahale.metrics.MetricRegistry`. If none is provided then Camel will create a shared instance used by the this CamelContext.
rateUnit	TimeUnit.SECONDS	The unit to use for rate in the metrics reporter or when dumping the statistics as json.
durationUnit	TimeUnit.MILLISECONDS	The unit to use for duration in the metrics reporter or when dumping the statistics as json.
namePattern	##name##.##routeId##.###id###.##type##	The name pattern to use. Uses dot as separators, but you can change that. The values ##name##, ##routeId##, ##type##, and ###id### will be replaced with actual value. Where ###name### is the name of the CamelContext. ###routeId### is the name of the route. The ###id### pattern represents the node id. And ###type### is the value of history.

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

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

+

The following options is supported on the factory:

Name	Default	Description
`useJmx`	`false`	Whether to report fine grained statistics to JMX by using the `com.codahale.metrics.JmxReporter`. Notice that if JMX is enabled on CamelContext then a `MetricsRegistryService` MBean is enlisted under the services type in the JMX tree. That MBean has a single operation to output the statistics using JSON. Setting `useJmx` to true is only needed if you want fine grained MBeans per statistics type.
`jmxDomain`	`org.apache.camel.metrics`	The JMX domain name.
`prettyPrint`	`false`	Whether to use pretty print when outputting statistics in JSON format.
`metricsRegistry`		Allow to use a shared `com.codahale.metrics.MetricRegistry`. If one is not provided Camel will create a shared instance for use by the `CamelContext``.`
`rateUnit`	`TimeUnit.SECONDS`	The unit to use for rate in the metrics reporter or when dumping the statistics as JSON.
`durationUnit`	`TimeUnit.MILLISECONDS`	The unit to use for duration in the metrics reporter or when dumping the statistics as JSON
`namePattern`	`##name##.##routeId##.###id###.##type##`	The name pattern to use. Uses dot as separators, but you can change that. The values `##name##`, `##routeId##`, `##type##`, and `###id###` will be replaced with actual value. Where `###name###` is the name of the `CamelContext.###routeId###` is the name of the route. The `###id###` pattern represents the node id, where `###type###` is the value of history.

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

In Java, get the service from the CamelContext as shown:

-

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

+

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