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 Exemplar Support to Client Java #622
Comments
Any thoughts on API design? For reference, the client_golang implementation was added in prometheus/client_golang#706 : //counters
Add(float64)
AddWithExemplar(value float64, exemplar Labels)
//histograms
Observe(float64)
ObserveWithExemplar(value float64, exemplar Labels) I'm inclined to follow the golang pattern and use distinct method names for exemplar method calls to reduce the risk of people confusing exemplar labels and metric labels. Does this seem reasonable? incWithExemplar(double value, String... exemplarLabels)
observeWithExemplar(double value, String... exemplarLabels) Or would a key/value wrapper be preferred? incWithExemplar(value, Label.of("key", "value")) Adding a label class that's only used for exemplars feels a little weird. |
In OpenTelemetry for Java, the current span context is always available via Span.current().getSpanContext() So the question is, what should our recommended way of dealing with exemplars in Java be? Explicit API calls where the user passes the trace ID as parameter, or implicit integration with OpenTelemetry, i.e. One argument for the implicit integration is that this will still work if the user does not call the |
One idea that had crossed my mind for exemplar recording would be initializing the counter/histogram with an optional The other option is to completely punt on that question and keep |
I am starting to love the idea that users enable OpenTelemetry in their application and automagically We could implement the I don't see any harm in providing an exemplar for each metric for each scrape. |
FYI I just pushed an |
I just opened a PR #652. Comments are welcome :) |
General comment... |
The final implementation is now merged to the |
Feature Request:
Addition of exemplar support to the previously merged OM support: #615
Thanks for working on this!
The text was updated successfully, but these errors were encountered: