Should labels.Labels.Hash() be consistent?

26 views
Skip to first unread message

Bryan Boreham

unread,
Nov 9, 2022, 10:11:15 AM11/9/22
to Prometheus Developers
As part of #10991 I took advantage of the new data structure to make Hash() run a lot faster; however the new version gives different answers to the old version. From my reading of the Prometheus code, this is OK because hash values are never persisted.

Later, I became aware that query-sharding in Mimir used this Hash function in persisted values. That is on Mimir (i.e. me) to fix.

My question to the group is: are there likely to be other places where it was assumed this value will never change?  I can change the labels.Labels API to have a new FastHash() or similar which is used in performance-sensitive places, and reinstate the old slow one.

Either way I would add to the docs whether Hash() should be expected to change.

Bryan

Bryan Boreham

unread,
Nov 28, 2022, 11:19:03 AM11/28/22
to Prometheus Developers
I talked to people about this at PromCon recently; the consensus was that Prometheus does not expect that Labels.Hash() is constant across runs of Prometheus.

Possible issues:
* The 'hashmod' function in relabelling: this uses a MD5 hash, separate from Labels.Hash().
* Alert.String() calls Labels.Hash().  I could not find where this was used.

I created https://github.com/prometheus/prometheus/pull/11635 to add a comment warning it may change.

Bryan
Reply all
Reply to author
Forward
0 new messages