no jvm metrics gathering because of wrong order of Bean registrations

Having plugged in spring-boot-starter-actuator and micrometer-registry-graphite into my Spring Boot 2 Application, the only metrics i get are those from Hikari Pool. No others like jvm or system ones.

After extensive debugging, i found out that the order of bean registrations might be a problem in my app. Disclaimer: I only added those 2 deps and added 3 lines of spring boot config. So no manual wiring with classes on my side.

The problem in detail seems to be that MeterRegistryPostProcessor @Bean in MetricsAutoConfiguration.class is instanciated before the GraphiteMeterRegistry @Bean in GraphiteMetricsExportAutoConfiguration.class.

The result is that the PostProcessor is not applied on the GraphiteRegistry and thus no configuration is being done on it.

Looking at the class mentioned class:

@Configuration
@AutoConfigureBefore({ CompositeMeterRegistryAutoConfiguration.class,
		SimpleMetricsExportAutoConfiguration.class })
@AutoConfigureAfter(MetricsAutoConfiguration.class)
@ConditionalOnBean(Clock.class)
@ConditionalOnClass(GraphiteMeterRegistry.class)
@ConditionalOnProperty(prefix = "management.metrics.export.graphite", name = "enabled", havingValue = "true", matchIfMissing = true)
@EnableConfigurationProperties(GraphiteProperties.class)
public class GraphiteMetricsExportAutoConfiguration {
...
}

There is a @AutoConfigureAfter annotation. What i dont get is, what does that mean, does it mean that this GraphiteMetricsExportAutoConfiguration @Configuration should be run after MetricsAutoConfiguration or vice versa?

Since i dont control any of those classes and i also dont use them programmatically, i dont know what to do on my side. I tried to replace the GraphiteMetricsExportAutoConfiguration with my own implementation but that didnt work. Perhaps i need to fork the micrometer-registry-graphit and play around with some modifiations on that, but have done yet.

[izeye]

@logemann Thanks for the sample!

ShiroFilterFactoryBean which is a BeanPostProcessor and has a dependency on DefaultWebSecurityManager will trigger early initialisation. I reworked it to prevent ShiroFilterFactoryBean from triggering early initialisation and created https://github.com/logemann/sample-micrometer-spring-boot/pull/1 against your fork.

Closing as this doesn’t seem to be a Micrometer issue.

[Wubbwubb]

I think I’ve found a possible reason for the problem.

In my application I used an autowired RestTemplateBuilder in some of my Service classes. The RestTemplateAutoConfiguration caused the trouble with the AutoConfiguration order, since the PrometheusMetricsExportAutoConfiguration was called by the RestTemplateAutoConfiguration (before MetricsAutoConfiguration).

After I removed the autowired RestTemplateBuilders the PrometheusMetricsExportAutoConfiguration has been configured after MetricsAutoConfiguration - like the annotation @AutoConfigureAfter in PrometheusMetricsExportAutoConfiguration says…