ObservationRegistry is never post-processed

[mmoayyed]

Describe the bug

I am running a Spring Boot web application with JDK 21 with the following versions/components:

springBootVersion=3.3.2
springVersion=6.1.12
micrometerVersion=1.13.3
springSecurityVersion=6.3.2

This application is tasked to simply review metrics produced by the metrics endpoint. With the above components, I begin to see warnings like this:

2024-08-20 19:21:58,213 WARN [org.springframework.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - 
<Bean 'org.springframework.boot.actuate.autoconfigure.observation.ObservationAutoConfiguration' of type [org.springframework.boot.actuate.autoconfigure.observation.ObservationAutoConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected into a currently created BeanPostProcessor [casBeanValidationPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies.>

2024-08-20 19:21:58,298 WARN [org.springframework.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - 
<Bean 'observationRegistry' of type [io.micrometer.observation.SimpleObservationRegistry] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected into a currently created BeanPostProcessor [casBeanValidationPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies.>

Furthermore, the observation registry created by Spring Boot,

    @Bean
	@ConditionalOnMissingBean
	ObservationRegistry observationRegistry() {
		return ObservationRegistry.create();
	}

...is never post-processed via ObservationRegistryPostProcessor, and as a result quite a number of metrics end up missing, particularly those that deal with http.server.requests and family.

Why Spring Security?

If I keep everything EXACTLY THE SAME and only go back to springSecurityVersion=6.3.1,

• All warnings disappear
• The missing metrics are restored.

I am not seeing anything relevant from the commit log, but I could be missing something. Again, the only thing that I do change from run to run is the Spring Security version; everything else is exactly the same as before.

Expected behavior

Http exchanges should be collected and exported as metrics.

Sample

I am working on a sample that would hopefully produce this but this might do, although I have to apologize as it's not really a lightweight thing:

git clone git@github.com:mmoayyed/cas.git cas
cd cas
cd webapp/cas-server-webapp-tomcat
casmodules="reports"
./gradlew bootRun \
	--configure-on-demand --build-cache \
	--parallel -DskipAot=true -x test -x javadoc -x check -DenableRemoteDebugging=true \
	--stacktrace -DskipNestedConfigMetadataGen=true \
	-DcasModules=${casmodules}

The application settings that control default SSL settings, etc with Spring Boot are defined in:

cas/webapp/cas-server-webapp-resources/src/main/resources/application.properties

If I can help further, please let me know.

[mmoayyed]

I suspect this commit is the problem:
27af1df#diff-05ce4e6526d12629e7ce3e84d1820ca22f23e20c13274705b1780fd126dc35c7

In particular,
27af1df#diff-05ce4e6526d12629e7ce3e84d1820ca22f23e20c13274705b1780fd126dc35c7R136-R145

(This bit is certainly different in 6.3.1)

Logs indicate:

2024-08-20 20:19:11,003 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] - <Creating shared instance of singleton bean 'authorizationProxyFactory'>
2024-08-20 20:19:11,032 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] - <Creating shared instance of singleton bean '_prePostMethodSecurityConfiguration'>
2024-08-20 20:19:11,036 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] - <Creating shared instance of singleton bean 'observationRegistry'>
2024-08-20 20:19:11,037 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] - <Creating shared instance of singleton bean 'org.springframework.boot.actuate.autoconfigure.observation.ObservationAutoConfiguration'>
2024-08-20 20:19:11,037 WARN [org.springframework.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - <Bean 'org.springframework.boot.actuate.autoconfigure.observation.ObservationAutoConfiguration' of type [org.springframework.boot.actuate.autoconfigure.observation.ObservationAutoConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected into a currently created BeanPostProcessor [casBeanValidationPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies.>
2024-08-20 20:19:11,123 WARN [org.springframework.context.support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - <Bean 'observationRegistry' of type [io.micrometer.observation.SimpleObservationRegistry] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected into a currently created BeanPostProcessor [casBeanValidationPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies.>

Creating _prePostMethodSecurityConfiguration likely leads to eager initialization of the observation registry.

[jzheaux]

@mmoayyed, thanks for the timely and detailed report. I've pushed a change that I believe repairs the issue. It will be available as 6.3.3-SNAPSHOT after the CI completes. Can you please confirm that it addresses the issue?

Also, I've added spring-projects/spring-security-samples#313 to improve our testing around Security together with ObservationRegistry.

[mmoayyed]

Thank you very much for the fix. I can confirm the issue is no longer there; all startup warnings are gone and I can correctly see the appropriate metrics. Cheers!

[mmoayyed]

By the way, I see that 6.3.3 is scheduled to be released on Oct 21st. That seems a little too far, wouldn't you agree, given the severity level of this bug? Do you think it makes sense to move up the release schedule to get this bug fix out? (I can of course stay on 6.3.1 for the time being, so not a blocker really).