feat(om2.0): have one line for classic-native histogram#2863
feat(om2.0): have one line for classic-native histogram#2863
Conversation
Otherwise rules around label set uniqeness, timestamps are violated. Also this should be more consistent and easier on the implementation. Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
| An example of Exemplars showcasing several valid cases: | ||
| The Histogram Sample with Native Buckets has multiple Exemplars. | ||
| The "0.01" bucket has no Exemplar. The 0.1 bucket has an Exemplar with no Labels. The 1 bucket has an Exemplar with one Label. The 10 bucket has an Exemplar with a Label and a timestamp. In practice all buckets SHOULD have the same style of Exemplars. | ||
| In case of a Histogram with both Classic and Native Buckets, only the exemplars belonging to the Classic Buckets MUST be |
There was a problem hiding this comment.
For histogram exemplars, we currently have:
Within classic buckets:
A Histogram MetricPoint MAY have exemplars. The values of exemplars in a Histogram MetricPoint SHOULD be evenly distributed, such as by keeping one exemplar for each Classic Bucket.
Within native buckets:
A Histogram MetricPoint with Native Buckets MAY contain exemplars.
The values of exemplars in a Histogram MetricPoint with Native Buckets SHOULD be evenly distributed to avoid only representing the bucket with the highest value and therefore most common case.
I don't like framing exemplars as "belonging" to classic or native buckets (although the classic bucket section mentions it as an example). WDYT about just consolidating the exemplar text for histogram OUT of the classic and native bucket sections? Something like:
A Histogram MetricPoint MAY have exemplars. The values of exemplars in a Histogram MetricPoint
SHOULD be evenly distributed, such as by keeping one exemplar for each Classic Bucket if Classic
Buckets are included.
There was a problem hiding this comment.
It doesn't prohibit having the separate exemplars implementation that client_golang has , so technically it's ok.
I'm a little bit afraid of people taking it as an indication that client_golang is wrong. But I'm not sure where to handle that. Maybe in the exposition we could turn it around and say that if you expose Classic Histograms (or both Classic and Native), then every exemplar must fall into exactly one classic bucket and no classic buckets can have multiple exemplars associated with it. So that you can convert into classic series with single exemplar each ?
There was a problem hiding this comment.
every exemplar must fall into exactly one classic bucket
OTel can produce non-bucket-aligned exemplars for fixed-bucket (classic) histograms. I'm hoping that the language can allow just putting those directly in the text format, rather than having to map to buckets and drop ones that aren't 1:1.
The intent with "such as by keeping one exemplar for each Classic Bucket if Classic Buckets are included." is to clearly bless the current behavior without requiring it. What makes you think it points to client_golang being wrong? Are you worried that allowing non-bucket-aligned exemplars will mean people push to have the SDK no longer store them that way?
I would be open to considering something like if classic buckets are included, there SHOULD be at most one exemplar for each classic bucket. But i'm not sure that makes the life of the scraper much easier, since it isn't a requirement and it still needs to handle the case where exemplars are not bucket-aligned.
| foo {count:17,sum:324789.3,bucket:[0.01:0,0.1:8,1.0:11,10.0:17,+Inf:17]} st@1520430000.123 # {} 0.054 1520879607.7 # {trace_id="KOO5S4vxi0o"} 0.67 1520879602.890 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789 | ||
| ``` | ||
|
|
||
| An example of a Histogram with Classic Buckets where the "0.01" bucket has no Exemplar. The 0.1 bucket has an Exemplar with no Labels. The 1 bucket has an Exemplar with one Label. The 10 bucket has an Exemplar with a Label and a timestamp. In practice all buckets SHOULD have the same style of Exemplars. |
There was a problem hiding this comment.
nit: prefer keeping normative language and examples separate.
| foo {count:17,sum:324789.3,bucket:[0.01:0,0.1:8,1.0:11,10.0:17,+Inf:17]} st@1520430000.123 # {} 0.054 1520879607.7 # {trace_id="KOO5S4vxi0o"} 0.67 1520879602.890 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789 | ||
| ``` | ||
|
|
||
| An example of a Histogram with Classic Buckets where the "0.01" bucket has no Exemplar. The 0.1 bucket has an Exemplar with no Labels. The 1 bucket has an Exemplar with one Label. The 10 bucket has an Exemplar with a Label and a timestamp. In practice all buckets SHOULD have the same style of Exemplars. |
There was a problem hiding this comment.
Nit: prefer phrasing as "Exemplar falls within the X bucket", rather than "X bucket has exemplar"
| foo {count:17,sum:324789.3,bucket:[0.01:0,0.1:8,1.0:11,10.0:17,+Inf:17]} st@1520430000.123 # {} 0.054 1520879607.7 # {trace_id="KOO5S4vxi0o"} 1.67 1520879602.890 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789 | ||
| ``` | ||
|
|
||
| An example of a Histogram with both Classic and Native Buckets, where the exemplars of only the Classic Buckets are |
There was a problem hiding this comment.
This would need to be updated if we changed the wording above
2 participants
Otherwise rules around label set uniqeness, timestamps are violated. Also this should be more consistent and easier on the implementation.