missing metrics after update from 5.3.2 to 5.3.3

[agebhar1]

Update from 5.3.2 to 5.3.3 (via Spring Boot Update from 2.3.4 to 2.3.5)

Describe the bug

Metrics for channels etc. are not provided by Prometheus endpoint /actuator/prometheus anymore.

To Reproduce

Metrics are missing if

@Bean
public MeterRegistry meterRegistry(PrometheusMeterRegistry registry) {
  return registry;
}

is not present (config/ApplicationConfiguration.java). The bean must be added explicit after update to 5.3.3 to enable metrics again.

Expected behavior

Not yes sure.

Sample

A almost simple sample is from a presentation demo

[artembilan]

Your sample is too complicated to play with on our side.

I'll try to come up with something very plain and we'll come back to you later.

[agebhar1]

I can provide a plain example tomorrow if it helps.

[artembilan]

Sure! That would be great!
I even think we don't need any complex flows.
Only your concern that there are no metrics for Spring Integration if that are no MeterRegistry bean.

I'm fully sure it is related to this: d60f235, but as far as I know Spring Boot auto-configures for us a CompositeMeterRegistry as a @Primary bean anyway.

So, yeah, as simple reproducable sample would be great and we will see at what point we are missing meters registration in Spring Integration.

[agebhar1]

Okay, I will provide such a simple sample (tomorrow).

[agebhar1]

Hello @artembilan a simple sample is set up https://github.com/agebhar1/si-3420-demo

[agebhar1]

The problem is

spring-integration/spring-integration-core/src/main/java/org/springframework/integration/support/management/micrometer/MicrometerMetricsCaptorRegistrar.java

Lines 52 to 65 in 1dd0315

	@Override
	public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {
	ListableBeanFactory beanFactory = (ListableBeanFactory) registry;
	if (METER_REGISTRY_CLASS != null
	&& !registry.containsBeanDefinition(MicrometerMetricsCaptor.MICROMETER_CAPTOR_NAME)
	&& beanFactory.getBeanNamesForType(METER_REGISTRY_CLASS, false, false).length > 0) {
	registry.registerBeanDefinition(MicrometerMetricsCaptor.MICROMETER_CAPTOR_NAME,
	BeanDefinitionBuilder.genericBeanDefinition(MicrometerMetricsCaptor.class)
	.addConstructorArgValue(beanFactory.getBeanProvider(METER_REGISTRY_CLASS))
	.setRole(BeanDefinition.ROLE_INFRASTRUCTURE)
	.getBeanDefinition());
	}
	}

Without an explicit bean of type MeterRegistry the condition fails.

[artembilan]

Thank you!

I will look into this shortly

[artembilan]

It looks like we also need to fix Spring Boot and make an IntegrationAutoConfiguration to be auto-configured after a CompositeMeterRegistryAutoConfiguration. Or vise-versa.

For time being the workaround is:

Place into a resources/META-INF the spring-autoconfigure-metadata.properties file with content:

org.springframework.boot.actuate.autoconfigure.metrics.CompositeMeterRegistryAutoConfiguration.AutoConfigureBefore=org.springframework.boot.autoconfigure.integration.IntegrationAutoConfiguration

This way Spring Boot builds for us its MeterRegistry bean and only after that IntegrationAutoConfiguration.IntegrationManagementConfiguration does its job with the mentioned MicrometerMetricsCaptorRegistrar logic. So, the condition registry.containsBeanDefinition(MicrometerMetricsCaptor.MICROMETER_CAPTOR_NAME) turns true and meters for Spring Integration components are registered with the Prometheus.

Now all your tests are passing, even without that custom register configuration property and those MeterRegistry explicit beans.

[agebhar1]

Thank you for the instant help. The proposed workaround is truly smart and I mentioned it on the sample project. All tests pass now.

[artembilan]

@agebhar1 ,

thanks for confirmation, but for more cleaner picture consider to remove those explicit MeterRegistry from your configuration and don't use register property in the tests.

I'll see with Spring Boot team what we can do over there.

[agebhar1]

@artembilan I updated the workaround branch accordingly.

Thank you.