You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
And bad:
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.
The text was updated successfully, but these errors were encountered: