MDC, ObservationRegistry, Tracer, Metrics are 4 observability entry points. MDC and Metrics.globalRegistry are accessible staticly - I see that it simplifies my code.

I'm not sure about ObservationRegistry. Here https://spring.io/blog/2022/10/12/observability-with-spring-boot-3#how-does-micrometer-observation-work is code snippet

ObservationRegistry registry = ObservationRegistry.create();

but not clear if it is good practice or not.

I observe Spring Boot is evolving to integrate observability entrypoints into single facade. I would like to joint the evolution, but I'm not convinced why I have to leave simple static API.

Considering that static Metrics.globalRegistry is supported by Spring, I propose to add similiar support for ObservationRegistry and Tracer

Comment From: bclozel

I think this is a question for the micrometer team, as the ObservationRegistry doesn't provide a static default.

Even if this was possible, I would say that relying on static fields creates a lot of lifecycle and configuration issues and we (the Spring Boot team) probably wouldn't choose this path.

Comment From: michaldo

I think this is a question for the micrometer team, as the ObservationRegistry doesn't provide a static default.

Even if this was possible, I would say that relying on static fields creates a lot of lifecycle and configuration issues and we (the Spring Boot team) probably wouldn't choose this path.

OK, I will call micrometer team.

BTW, Spring Boot supports static Metrics - I think there is a reason: https://docs.spring.io/spring-boot/reference/actuator/metrics.html#actuator.metrics.getting-started

Spring Boot also adds any auto-configured registries to the global static composite registry on the Metrics class, unless you explicitly tell it not to:

Comment From: bclozel

@michaldo yeah we had multiple issues with this mix of static/non static, and more importantly lifecycle issues with early initializations. Again, even if the Micrometer team agrees to have a static version of this I don't think we'll follow through in Spring Boot.

Comment From: michaldo

Well, Micrometed team added static global observation registry 2 months ago (io.micrometer.observation.Observations#getGlobalRegistry)

I do not know well issue with static and lifecycle, but as a layman I see that now initialization is

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

and could be 

@Bean
@ConditionalOnMissingBean
ObservationRegistry observationRegistry() {
  return global ? Observations.getGlobalRegistry() : ObservationRegistry.create();
}

It does not look more risky than original one

Comment From: bclozel

https://github.com/micrometer-metrics/micrometer/pull/5700 shows that the Micrometer team does not consider this a best practice, so we'll leave things as they are in Spring Boot.

Comment From: michaldo

Funny that the Micrometer team closed the request answering that it not best practice instead of answering that global registry is implemented by marcingrzejszczak since Jun 2024.

Anyway, I'm leaving this issue with better knowledge of observability and I know that if I want convenient observability code it is enough to declare @Bean ObservationRegistry observationRegistry() { return Observations.getGlobalRegistry();}

(I can rely that in any place in code I call Observations.getGlobalRegistry(), I will get the registry configured by Spring Boot

Thanks for cooperation

Comment From: bclozel

It's your choice. Note that by doing that, all customizations on the ObservationRegistry performed before the application context is started might be overwritten by the Spring Boot auto-configuration.