Metrics auto-configurations that depend on a MeterRegistry bean should be configured AFTER configurations that create the MeterRegistry. However, @AutoConfigureAfter(MetricsAutoConfiguration.class) is not sufficient. MetricsAutoConfiguration does not export a MeterRegistry.

This commit changes the @AutoConfigureAfter annotations so that the proper ordering of configurations in ensured.

The long story:

I ran into issues in one of my spring-boot services when trying to fix a Micrometer bug. After adding a simple custom auto-configuration with dependency on MeterRegistry and LogbackMetrics, the application failed to start because of a missing LogbackMetrics dependency. Debug output showed that the LogbackMetricsAutoConfiguration is disabled because the condition @ConditionalOnBean(MeterRegistry.class) is not met. After more debugging I found out that LogbackMetricsAutoConfiguration was evaluated before PrometheusMetricsExportAutoConfiguration.

I created a sample project that demonstrates this issue.

A simple workaround that I currently use in my projects is a dummy auto-configuration that inserts itself between LogbackMetricsAutoConfiguration and configurations that create the MeterRegistry:

@Configuration
@AutoConfigureAfter({ CompositeMeterRegistryAutoConfiguration.class, SimpleMetricsExportAutoConfiguration.class })
@AutoConfigureBefore({
        JvmMetricsAutoConfiguration.class,
        KafkaMetricsAutoConfiguration.class,
        Log4J2MetricsAutoConfiguration.class,
        LogbackMetricsAutoConfiguration.class,
        SystemMetricsAutoConfiguration.class
})
public class ProperMetricsOrderingAutoConfiguration {
    // empty
}

Comment From: pivotal-issuemaster

@bendiscz Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-issuemaster

@bendiscz Thank you for signing the Contributor License Agreement!

Comment From: bendiscz

Did you fix those 5 auto-configurations because you were affected by them or have you reviewed all of them and those particular 5 were a problem?

I was directly affected by LogbackMetricsAutoConfiguration. Then I checked all other metrics auto-configurations in the same package and saw that they have the same problem.

Comment From: philwebb

Possible related to #11890

Comment From: philwebb

Thanks very much for the PR @bendiscz. One of the reasons we've got away with this for so long is that CompositeMeterRegistryAutoConfiguration just happens to be alphabetically before the configurations that use it.

Unfortunately, despite my best efforts, I couldn't find an easy way to test the fix. Each test I tried ended up causing a order cycle. I'm pretty confident with the fix, so we'll have to just run with it.