Label order in textformat

[kwiesmueller]

One thing I'm missing from the textformat is, that the order of label keys is expected to remain consistent in a single scrape of a histogram bucket

So, good:

# TYPE foo histogram
foo_bucket{a=x,b=x,le="0.0"} 0
foo_bucket{a=x,b=x,le="0.1"} 8
foo_bucket{a=x,b=x,le="+Inf"} 17

And bad:

# TYPE foo histogram
foo_bucket{a=x,b=x,le="0.0"} 0
foo_bucket{b=x,a=x,le="0.1"} 8 # here a and b are switched
foo_bucket{a=x,b=x,le="+Inf"} 17

This guarantee could help parsers be more efficient as they can compare labels using simple string comparing vs. decoding the labels into maps first and then comparing those.

[brian-brazil]

The 2nd example is sufficient in my experience (though weird), the more important thing is that it's consistent from scrape to scrape which is encouraged by the spec but not required so that you can cache the labels and do a hash lookup across scrapes.

Making it consistent from scrape to scrape is also likely going to make it consistent within a scape, as the easiest way is some form of sorting. So I don't think this requires any changes in the spec, as it'll already largely ensure this.

[krajorama]

In OM 2.0 we plan to change the way that classic histograms and summaries are exposed. It would mean that an instance of a histogram or summary (i.e. MetricPoint) would be represented on a single line, instead of multiple lines. That would fix the use case example above. See #283.

[bwplotka]

This is now fixed in 2.0 as we proposed composite values.