New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-configuration ignores user-provided ObservationConventions #33285
Comments
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? |
@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? |
That does help, I was unaware that multiple implementations to the |
Thanks! |
We've also addressed this in the reference documentation in #33281 |
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. |
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. |
With the move to micrometer observability, the
WebClientExchangeTagsProvider
andRestTemplateExchangeTagsProvicer
have both been deprecated in favour ofObservationConvention
s.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
The text was updated successfully, but these errors were encountered: