Conversation
Due to classic and native buckets we now have a special case for the timestamps rule. Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
| * Two Histogram MetricPoints where one has Classic Buckets and the other has Native Buckets. | ||
| * Two GaugeHistogram MetricPoints where one has Classic Buckets and the other has Native Buckets. | ||
|
|
||
| Note: these exemptions allow exposing both Classic and Native Buckets for the |
There was a problem hiding this comment.
Sorry if this is a can of worms...
Did we already discuss having classic + native on the same line?
If we keep them on separate lines, I think we need more updates to the spec. E.g.
MetricFamily
A MetricFamily MAY have zero or more Metrics. A MetricFamily MUST have a name, HELP, TYPE, and UNIT metadata. Every Metric within a MetricFamily MUST have a unique LabelSet.
We need to carve out an exception from "MUST have a unique LabelSet" for this.
There was a problem hiding this comment.
Sorry if this is a can of worms...
Did we already discuss having classic + native on the same line?
No, we have not. I think the fallout from that would be worse than having two lines.
- Readability would be worse.
- Native and classic bucketing has different exemplars so where do you put those?
- One composite value per line no longer true.
- probably more...
If we keep them on separate lines, I think we need more updates to the spec. E.g.
MetricFamily
A MetricFamily MAY have zero or more Metrics. A MetricFamily MUST have a name, HELP, TYPE, and UNIT metadata. Every Metric within a MetricFamily MUST have a unique LabelSet.We need to carve out an exception from "MUST have a unique LabelSet" for this.
True.
2 participants
Due to classic and native buckets we now have a special case for the timestamps rule.