Open lampad opened 2 hours ago
Hey @lampad, thanks for writing this up!
I'm going to take some time to read through the thread you linked and the related Prometheus docs. My gut take from a quick look is that this isn't something we're going to unilaterally decide over here in client_ruby
. It's a convention agreed by the Prometheus team and implemented equally in the different client libraries.
If that ends up being the conclusion I come to after more reading, and you would like to pursue the wider change, I'd suggest raising this for a discussion on the prometheus-developers mailing list.
Appreciate the attention @Sinjo !
I think this will probably be the piece we'll end up discussing the most from the docs:
Client libraries MUST NOT allow users to have different label names for the same metric for Gauge/Counter/Summary/Histogram or any other Collector offered by the library.
One could argue semantics of a metric with the same name but different labels being a different metric altogether, but I think I'd also like to challenge that general concept of disallowing different label names on a metric, or at least get a bit more context as to why this seems to be such a firm directive.
To me it seems really useful to allow for varying labels as a method of grouping metrics in different ways for reporting and observability. In a distributed setting, for different components producing the same thing in different contexts it also seems useful that those components wouldn't need to know the labels being set by their counterpart if they're incrementing a counter with the same name for example.
In any case, interested to hear your thoughts after you do a bit more reading.
Currently the prometheus client does not allow you to register multiple metrics with the same name but different labels:
This has been discussed elsewhere without any real conclusion, but after looking through the code, it seems relatively simple to allow this functionality in the ruby client registry by building a natural key of the metric name and possible label keys before sticking it in the registry.
Allowing this flexibility in label setting would make monitoring apps in distributed settings much easier and allow for more flexibility from a user/client standpoint by not having to know all labels up front.
I'd be happy to submit a PR if there's appetite for this change.