Allow multiple exemplars on counters and histograms#2838
Open
dashpole wants to merge 1 commit intoprometheus:mainfrom
Open
Allow multiple exemplars on counters and histograms#2838dashpole wants to merge 1 commit intoprometheus:mainfrom
dashpole wants to merge 1 commit intoprometheus:mainfrom
Conversation
Signed-off-by: David Ashpole <dashpole@google.com>
bwplotka
reviewed
Feb 11, 2026
| If the NaN value is allowed, it MUST be counted in the +Inf bucket, and MUST NOT be counted in any other bucket. The rationale is that NaN does not belong to any bucket mathematically, however instrumentation libraries traditionally put it into the +Inf bucket. | ||
|
|
||
| Classic Bucket values MAY have exemplars. The value of the exemplar MUST be within the Classic Bucket. Exemplars SHOULD be put into the Classic Bucket with the lowest threshold that includes the exemplar value. A Classic Bucket MUST NOT have more than one exemplar. | ||
| Classic Bucket values MAY have exemplars. The value of the exemplar SHOULD be within the Classic Bucket. Exemplars SHOULD be put into the Classic Bucket with the lowest threshold that includes the exemplar value. A Classic Bucket SHOULD NOT have more than one exemplar. |
Member
There was a problem hiding this comment.
WG notes
- It's typical in Otel to go outside
- How this works for native histograms? Separate storages? We could switch to the language native histograms uses - "evenly distributed". As long as it's evenly distributed, it's fine if it's not within buckets.
- Krajo: For classic histograms are by design it's inside bucket. For classic histograms we can have only one exemplar per bucket. We can refine this to say similar thing to native histograms. In Go SDK exemplars storages are different for native vs classic (although on proto it's one field - to be checked).
Member
There was a problem hiding this comment.
- How this will work with 1.0 compatible storage
Member
There was a problem hiding this comment.
- K: Maybe we should say one exemplar per bucket? We could change over time.
- D: What's value of saying MUST
- K: Either be strict (same as before), or be relaxed and lose exemplars for 1.0 - it's likely fine
Member
There was a problem hiding this comment.
K: We need to rewrite this rule as this applies in a different way (composite) - should be one per bucket / align wording
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Fixes prometheus/OpenMetrics#311
Remove the restriction on having a single exemplar on counters. This matches PRW 2.0, OpenTelemetry, and makes exemplars more consistent between types.
While reading through exemplar language, I noticed the MUST requirement for histogram-bucket-aligned exemplars on fixed-bucket histograms. This relaxes (to SHOULD) the alignment of exemplars with histogram buckets. This is done because: