Dimensions are order-sensitive

[arielb1]

This creates 2 different gauges, which is probably not what you want, since the order of the dimensions differs between the two:

            gauge!("my_gauge", "foo" => "0", "bar" => "1").increment(1);
            gauge!("my_gauge", "bar" => "1", "foo" => "0").increment(1);

I saw this happen when using a HashMap for dimensions, and the HashMap getting a different order every time. This behavior should at least be better documented.

[tobz]

Hmm, agreed.

This would be an exporter implementation detail, whether or not they dedupe labels and/or sort them... but it could stand be called out at a high-level as such, rather than leaving it open to assuming that metrics itself somehow dedupes/sorts labels for you.

If you're willing to contribute a PR, that would be great. It'll probably take me some time to get to it otherwise.

[arielb1]

It's not obvious how an exporter would aggregate gauges post-facto. And if an exporter wants to make the calls to register_gauge return the same gauge for both orders, they can't use the Hash implementation on Key since it's order sensitive. For counters and histograms, there's at least an obvious aggregation method, tho people can still call Counter::absolute.

[tobz]

I was referring to doing it pre-facto. :)

Exporters aren't beholden by the hashing that happens implicitly in Key: they could use a newtype wrapper with order-insensitive hashing and deduplication, etc. Practically speaking, almost all exporters I've written or seen just use the existing Key hash, but it's not required to do so.