KeyValues on Observation.Event #6003
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Pinging @lenin-jaganathan and @ThomasVitale who were asking for this. I'm not sure whether this API serves the purpose you had in mind, but I figured it may be easier to start with something concrete to discuss. |
| * @return event | ||
| * @since 1.15.0 | ||
| */ | ||
| static Event of(String name, String contextualName, long wallTime, Iterable<KeyValue> keyValues) { |
There was a problem hiding this comment.
I think in the handlers event keyvalues can be used:
- Low cardinality keyvalues can be attached to metrics: right now we create a counter, we can merge the low cardinality keyvalues of the observation with the the low cardinality keyvalues of the event.
- All keyvalues (low+high) can be attached to the annotation of the span (in case of zipkin we can encode it to
k1=v1;k2=v2format I think).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening for discussion related to implementing #5238. It's been implemented in a way that nothing should break.
I intentionally did not separate out high- vs low-cardinality keyvalues. I'd be interested to hear feedback on if it's needed and why.
I think most of the real impact is in how this will be handled: by our DefaultMeterObservationHandler, our default tracing handler, and other handlers.