-
Notifications
You must be signed in to change notification settings - Fork 805
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
Add exemplars support for Micrometer Tracing #805
base: main
Are you sure you want to change the base?
Add exemplars support for Micrometer Tracing #805
Conversation
Signed-off-by: Jonatan Ivanov <[email protected]>
68cdf76
to
1d5e4c7
Compare
Also, do you happen to know why the javadoc goal is failing? The error message does not seem to be very helpful. |
ExemplarSampler exemplarSampler = new DefaultExemplarSampler(new MicrometerTracingSpanContextSupplier(tracer)); | ||
ExemplarConfig.setCounterExemplarSampler(exemplarSampler); | ||
ExemplarConfig.setHistogramExemplarSampler(exemplarSampler); | ||
ExemplarConfig.enableExemplars(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just read your comment above again. Yes, the current implementation in Tracer.findSpanContextSupplier()
assumes that it can get a tracer from a static variable. In that case client_java
will use that tracer automatically, and users don't need any explicit code for that.
However, if the tracer is not available via a static variable, you need to set it explicitly as in your example above. I don't see any other way how to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry again for dropping the ball. Thanks a lot for adding Micrometer tracer support for Examplars.
I will take another look at the initialization, but I think if there's no static variable to get the tracer, users will need to set the tracer explicitly as in your example.
Hello again, I had another look.
|
Heads-up: I renamed |
javadoc: 🤦🏼 🤣 I'm sorry. static initialization
Spring and other CDI solutions will initialize their context after class loading (by creating non-static instances) so even if they inject something to a static context, that will happen (or can easily happen without control) after the java client's static initializers were executed. Also, since they can (and will) inject the registry, the global/static components are less useful in those environments (in fact they can cause trouble and make testing hard/impossible). This is my honest feedback, I don't want to offend anyone or step on any toes (also, I'm biased): I think the Prometheus Java Client should focus on letting CDI/users configure things in non-static ways (providing builders with defaults and factory methods are completely ok). I think it could also use a
If Micrometer Tracing adds support for another Tracing library or Prometheus Client adds support for another Tracing library (i.e.: Brave) or both, this will increase quickly |
This PR adds exemplars support for Micrometer Tracing.
Micrometer Tracing is the successor of Spring Cloud Sleuth in terms of providing an abstraction layer over tracing libraries (i.e.: Brave and OTel) and it provides distributed tracing support for the Spring portfolio (Spring Boot 3.x, Spring Framework 6.x, etc).
There is one thing missing from this PR where I would like to ask for some guidance from the maintainers: there is no static configuration. Since Micrometer Tracing needs a
Tracer
instance and it supports both Brave + OTel (Brave does not have static config) this might be problematic since users can use their ownTracer
instance that might be different than the Prometheus client is aware of.@fstab @tomwilkie