to remind ourselves about the prometheus types and their differences and when to use what: https://prometheus.io/docs/concepts/metric_types/
The patch I got in makes all the tor_relay_connections_total{} metrics "gauges" because in effect, some can go up and down and some might only go up but I figured even the one that only accumulate can also be gauges.
you are right that prometheus will scrape it anyway even if the type is incorrectly defined but by defining a counter as gauge (or vice versa) you tell people what it is and how to make sense of it, for example the type implies "do (not) use rate() on this".
By looking at
# TYPE tor_relay_connections_total gauge [...]
Anyone familiar with prometheus would expect it to be a gauge - so for example would not use rate() on it - but that is not correct for all labels. For example creating graphs for state="created" without using rate() would produce boring graphs because it is a counter. They might also wonder why a gauge ends with .._total, because that is used for accumulating count [1].
Is that a problem to your knowledge from a Prometheus standpoint?
It is a problem because prometheus users/tools are used to consume that TYPE line to learn what type it is. They will get confused if they treat it according to the current type definition. graphing counters as if they were gauges will result in questions like "oh why is my rate of x always increasing?"
before: # TYPE tor_relay_connections counter tor_relay_connections{type="OR",direction="initiated",state="opened"}
but that value is not a counter, it is a gauge. It can go down.
after yesterday's change:
# TYPE tor_relay_connections_total gauge tor_relay_connections_total{type="OR",direction="received",state="created"}
but that is a counter, it can never go down.
To prevent this and to follow the usual prometheus practices is best to have the current metric split into one for counters and another one for gauges.
thanks for working on this!
best regards, nat