SpringBoot Auto-configuration ignores user-provided ObservationConventions

With the move to micrometer observability, the WebClientExchangeTagsProvider and RestTemplateExchangeTagsProvicer have both been deprecated in favour of ObservationConventions.

The configuration (in this case the reactive but also affects the servlet) is not customizable enough to allow users to move off the deprecated classes.

The configuration should have means to accept a custom implementation of the ObservationConvention. Right now you would have to exclude this configuration class completely as the default convention is created in the bean method. See here: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/observation/web/client/WebClientObservationConfiguration.java#L53

Additional Context

I would like to migrate away from deprecated classes, but without being able to create my own ObservationConvention I cannot cleanly stop using the old TagsProvider's.

cc @bclozel excuse the tag, but mentioned as you created these configuration classes

Comment From: wilkinsona

Brian's been working on a migration guide for this. Does https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-Metrics-3.0#migrating-tag-providers-and-contributors help?

Comment From: bclozel

@braunsonm no worries.

Does this section of the migration guide helps? Could you tell us more about your use case and how we could improve it?

Comment From: braunsonm

That does help, I was unaware that multiple implementations to the ObservationRegistry effectively override the ones provided by Spring Boot. Thank you, this satisfies my use case.

Comment From: bclozel

Thanks!

Comment From: bclozel

We've also addressed this in the reference documentation in #33281

Comment From: braunsonm

Hey @bclozel We are not seeing it behave the way you describe in the documentation. Would you like a separate issue for this?

With a very simple example:

public class ExtendedClientRequestObservationConvention extends DefaultClientRequestObservationConvention implements
  GlobalObservationConvention<ClientRequestObservationContext> {
  @Override
  public KeyValues getLowCardinalityKeyValues(ClientRequestObservationContext context) {
    // Note the URI has been removed
    return KeyValues.of(method(context), status(context), exception(context), outcome(context));
  }
}

@Configuration
public class SampleConfiguration {
  @Bean
  ExtendedClientRequestObservationConvention sampleConvention() {
    return new ExtendedClientRequestObservationConvention();
  }
}

I can still see that the Default implementation is called, even when the bean is wired up.

Comment From: bclozel

Thanks @braunsonm - we've discussed this with @marcingrzejszczak and found that the current situation is not in line with the migration story we're expecting. I'm repurposing this issue to use ObservationConvention beans provided by the application as a way to customize key values. I've also updated the migration guide accordingly. You can test this approach with 3.0.0-SNAPSHOT as soon as this issue is resolved.