53. Metrics

53. Metrics
Prev	Part V. Spring Boot Actuator: Production-ready features	Next

Spring Boot Actuator provides dependency management and auto-configuration for Micrometer, an application metrics facade that supports numerous monitoring systems, including:

	Note
	At the time of this writing, the number of monitoring systems supported by Micrometer is growing rapidly. See the Micrometer project for more information.

Micrometer provides a separate module for each supported monitoring system. Depending on one (or more) of these modules is sufficient to get started with Micrometer in your Spring Boot application. To learn more about Micrometer’s capabilities, please refer to its reference documentation.

53.1 Spring MVC Metrics

Auto-configuration enables the instrumentation of requests handled by Spring MVC. When management.metrics.web.server.auto-time-requests is true, this instrumentation occurs for all requests. Alternatively, when set to false, you can enable instrumentation by adding @Timed to a request-handling method.

By default, metrics are generated with the name, http.server.requests. The name can be customized by setting the management.metrics.web.server.requests-metric-name property.

53.1.1 Spring MVC Metric Tags

By default, Spring MVC-related metrics are tagged with the following information:

The request’s method.
The request’s URI (templated if possible).
The simple class name of any exception that was thrown while handling the request.
The response’s status.

To customize the tags, provide a @Bean that implements WebMvcTagsProvider.

53.2 WebFlux Metrics

Auto-configuration enables the instrumentation of all requests handled by WebFlux controllers. You can also use a helper class, RouterFunctionMetrics, to instrument applications that use WebFlux’s functional programming model.

By default, metrics are generated with the name http.server.requests. You can customize the name by setting the management.metrics.web.server.requests-metric-name property.

53.2.1 WebFlux Metrics Tags

By default, WebFlux-related metrics for the annotation-based programming model are tagged with the following information:

The request’s method.
The request’s URI (templated if possible).
The simple class name of any exception that was thrown while handling the request.
The response’s status.

To customize the tags, provide a @Bean that implements WebFluxTagsProvider.

By default, metrics for the functional programming model are tagged with the following information:

The request’s method
The request’s URI (templated if possible).
The response’s status.

To customize the tags, use the defaultTags method on your RouterFunctionMetrics instance.

53.3 RestTemplate Metrics

The instrumentation of any RestTemplate created using the auto-configured RestTemplateBuilder is enabled. It is also possible to apply MetricsRestTemplateCustomizer manually.

By default, metrics are generated with the name, http.client.requests. The name can be customized by setting the management.metrics.web.client.requests-metric-name property.

53.3.1 RestTemplate Metric Tags

By default, metrics generated by an instrumented RestTemplate are tagged with the following information:

The request’s method.
The request’s URI (templated if possible).
The response’s status.
The request URI’s host.

53.4 Cache metrics

Auto-configuration will enable the instrumentation of all available Caches on startup with a metric named cache. The prefix can be customized by using the management.metrics.cache.metric-name property. Cache instrumentation is specific to each cache library, refer to the micrometer documentation for more details.

The following cache libraries are supported:

Caffeine
EhCache 2
Hazelcast
Any compliant JCache (JSR-107) implementation

Metrics will also be tagged by the name of the CacheManager computed based on the bean name.

	Note
	Only caches that are available on startup are bound to the registry. For caches created on-the-fly or programmatically after the startup phase, an explicit registration is required. A `CacheMetricsRegistrar` bean is made available to make that process easier.

53.5 DataSource Metrics

Auto-configuration enables the instrumentation of all available DataSource objects with a metric named data.source. Data source instrumentation results in gauges representing the currently active, maximum allowed, and minimum allowed connections in the pool. Each of these gauges has a name that is prefixed by data.source by default. The prefix can be customized by setting the management.metrics.jdbc.metric-name property.

Metrics are also tagged by the name of the DataSource computed based on the bean name.

53.6 RabbitMQ metrics

Auto-configuration will enable the instrumentation of all available RabbitMQ connection factories with a metric named rabbitmq. The prefix can be customized by using the management.metrics.rabbitmq.metric-name property.

53.7 Spring Integration Metrics

Auto-configuration enables binding of a number of Spring Integration-related metrics:

Table 53.1. General metrics

Metric	Description
`spring.integration.channelNames`	Number of Spring Integration channels
`spring.integration.handlerNames`	Number of Spring Integration handlers
`spring.integration.sourceNames`	Number of Spring Integration sources

Table 53.2. Channel metrics

Metric	Description
`spring.integration.channel.receives`	Number of receives
`spring.integration.channel.sendErrors`	Number of failed sends
`spring.integration.channel.sends`	Number of successful sends

Table 53.3. Handler metrics

Metric	Description
`spring.integration.handler.duration.max`	Maximum handler duration in milliseconds
`spring.integration.handler.duration.min`	Minimum handler duration in milliseconds
`spring.integration.handler.duration.mean`	Mean handler duration in milliseconds
`spring.integration.handler.activeCount`	Number of active handlers

Table 53.4. Source metrics

Metric	Description
`spring.integration.source.messages`	Number of successful source calls

Prev	Up	Next
52. Loggers	Home	54. Auditing