Actuator endpoints incldue one for getting application status (/actuator/info
) and another to get applicative metrics (/actuator/prometheus
).
In microservices/continuous deployments, as application version changes quite often, it would be cool to have the version info exposed through metrics.
As an example, here is what I'm doing to have version exposed
@Configuration
public class MonitoringConfiguration {
public MonitoringConfiguration(@Autowired BuildProperties buildProperties,
@Autowired MeterRegistry registry) {
Gauge.builder("app_build_info", 1.0, n -> n)
.strongReference(true)
.description("A metric with a constant ‘1’ value labeled by version, app_name, runtime version, and build time from which application was built.")
.tags("app_version", buildProperties.getVersion(),
"app_name", buildProperties.getName(),
"runtime_version", System.getProperty("java.version"),
"build_time", buildProperties.getTime().toString())
.register(registry);
}
}
(thanks @snahelou)
I think it woul be a good think to have that exposed directly through actuator, or in a actuator-extensions allowing easy usage by Spring boot projects.
Comment From: wilkinsona
You can use a MeterRegistryCustomizer
@Bean
and MeterRegistry.commonTags()
to add tags to every metric. There's an example showing this in the reference documentation:
@Bean
MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
return registry -> registry.config().commonTags("region", "us-east-1");
}
Comment From: snicoll
You could also add common tags via configuration. The example above can be rewritten as follows:
management.metrics.tags.region=us-east-1
Comment From: snahelou
Thank you for your quick reply.
So what you recommend is to add a tag on more than 200 metrics, instead of creating one ?
Strange... what about the storage/compute on the other side?
Comment From: wilkinsona
It sounds like we misunderstood the original request. I interpreted "it would be cool to have the version info exposed through metrics" to mean that the goal was to have the info properties available as tags on every metric.
If the goal is to publish a single metric derived from the info properties then the approach shown in the original description is fine. Alternatively, you can use a MeterBinder
@Bean
to perform the registration explicitly rather than as a side-effect of configuration class creation.
I don't think there's anything to change in Spring Boot here. The existing MeterBinder
@Bean
support is provided for binding custom metrics. We do not want to couple metrics and the info properties by default as we consider them to be separate concerns. In some cases, the data exposed via the info endpoint would not be appropriate to expose as metrics or metric tags.