Dear Spring Boot team,

I wanted to test the new feature from Spring Boot 2.5.0 MongdDB metrics.

Unfortunately after upgrade from 2.4.X to 2.5.0 seems "broken". I assumed that could be something with our Spring cloud dependencies but I was able recreate this with minimal Spring Intializer project.

The dependencies which I've added: - spring-boot-starter-actuator - spring-boot-starter-web - spring-boot-starter-data-mongodb - micrometer-registry-prometheus

  • standard settings to expose prometheus endpoint (you can take a look at attached project). With version 2.4.5 I have a full set of metrics:

SpringBoot Problem with prometheus metrics on 2.5.0 and mongodb autostarter include

In the next step the only thing which I'm changing is upgrade to Spring Boot 2.5.0. Then the metrics looks like:

SpringBoot Problem with prometheus metrics on 2.5.0 and mongodb autostarter include

So all the jvm, memory, etc. stuff disappear. There is not custom application tag added to metrics, etc. I've seen you mentioned about some response changes (https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.5-Release-Notes#openmetrics-for-prometheus) but I don't think it is related.

How to recreate: - download attached project and go to http://localhost:8081/actuator/prometheus - change spring version in pom.xml from 2.4.5 to 2.5.0 - one more time go to http://localhost:8081/actuator/prometheus and compare result

The mongo will be needed - I've added some example docker-compose in root project dir to quickly setup it.

demo.zip

Comment From: oridool

Happens to me as well. I noticed missing metrics. But also noticed that the common tags ('application=') don't appear anymore. For example: SpringBoot 2.4.5: tomcat_sessions_active_current_sessions{application="account",} 0.0 SpringBoot 2.5.0: tomcat_sessions_active_current_sessions 0.0

common tags are injected by:

    @Bean
    public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
        return registry -> registry.config().commonTags("application", "account");
    }

Comment From: underbell

I have the same problem and I use the r2dbc mysql. Metrics related to jvm are not measured. The case I checked is boot 2.4.6 and boot 2.5.0 It works fine in 2.4.6 and works fine in 2.5.0. However, if r2dbc mysql is used in 2.5.0, BeanPostProcessor is not processed normally.

trationDelegate$BeanPostProcessorChecker : Bean 'management.metrics-org.springframework.boot.actuate.autoconfigure.metrics.MetricsProperties' of type [org.springframework.boot.actuate.autoconfigure.metrics.MetricsProperties] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.boot.actuate.autoconfigure.metrics.data.RepositoryMetricsAutoConfiguration' of type [org.springframework.boot.actuate.autoconfigure.metrics.data.RepositoryMetricsAutoConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.boot.actuate.autoconfigure.metrics.export.prometheus.PrometheusMetricsExportAutoConfiguration' of type [org.springframework.boot.actuate.autoconfigure.metrics.export.prometheus.PrometheusMetricsExportAutoConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'management.metrics.export.prometheus-org.springframework.boot.actuate.autoconfigure.metrics.export.prometheus.PrometheusProperties' of type [org.springframework.boot.actuate.autoconfigure.metrics.export.prometheus.PrometheusProperties] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'prometheusConfig' of type [org.springframework.boot.actuate.autoconfigure.metrics.export.prometheus.PrometheusPropertiesConfigAdapter] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'collectorRegistry' of type [io.prometheus.client.CollectorRegistry] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.boot.actuate.autoconfigure.metrics.MetricsAutoConfiguration' of type [org.springframework.boot.actuate.autoconfigure.metrics.MetricsAutoConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'micrometerClock' of type [io.micrometer.core.instrument.Clock$1] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'prometheusMeterRegistry' of type [io.micrometer.prometheus.PrometheusMeterRegistry] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'repositoryTagsProvider' of type [org.springframework.boot.actuate.metrics.data.DefaultRepositoryTagsProvider] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
trationDelegate$BeanPostProcessorChecker : Bean 'metricsRepositoryMethodInvocationListener' of type [org.springframework.boot.actuate.metrics.data.MetricsRepositoryMethodInvocationListener] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

On a temporary basis, I've worked it out like this. But I hope there is a more principled solution.

@Bean
InitializingBean prometheusPostProcessor(
    BeanPostProcessor meterRegistryPostProcessor,
    PrometheusMeterRegistry prometheusMeterRegistry) {
  return () ->
      meterRegistryPostProcessor.postProcessAfterInitialization(prometheusMeterRegistry, "");
}

Comment From: snicoll

Thanks everyone for the feedback, and special kudos to @pnowy for the nice sample with docker-compose.

This regression has already been fixed in 2.5.1-SNAPSHOT, see #26630. Please test your project against 2.5.1-SNAPSHOT and let us know if there is still a problem for you.

Comment From: pnowy

@snicoll checked with 2.5.1-SNAPSHOT version - looks good. Thx for help!