Add :labels for Prometheus::Middleware::Collector

[benyitzhaki]

This pull request makes it possible to pass a labels argument that will add default labels to each metric exposed using the collector middleware.
Usage example:
config.middleware.use Prometheus::Middleware::Collector, { labels: { env: Rails.env } }

[coveralls]

Coverage remained the same at 100.0% when pulling c9e0f6e on benyitzhaki:master into 4f8de6c on prometheus:master.

[brian-brazil]

That sounds like a target label, which you're best off adding on the Prometheus end.

…

On Thu 6 Feb 2020, 14:33 Ben Yitzhaki, ***@***.***> wrote: This pull request makes it possible to pass a labels argument that will add default labels to each metric exposed using the collector middleware. Usage example: config.middleware.use Prometheus::Middleware::Collector, { labels: { env: Rails.env } } ------------------------------ You can view, comment on, or merge this pull request online at: #180 Commit Summary - add support for custom labels for the collector middleware File Changes - *M* lib/prometheus/middleware/collector.rb <https://github.com/prometheus/client_ruby/pull/180/files#diff-0> (29) Patch Links: - https://github.com/prometheus/client_ruby/pull/180.patch - https://github.com/prometheus/client_ruby/pull/180.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#180?email_source=notifications&email_token=ABWJG5RJDD67VWWAJ2BLNOTRBQGUFA5CNFSM4KQ465VKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILQNQWQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWJG5RWJ2IBUGWYYV3TK5DRBQGUFANCNFSM4KQ465VA> .

[Sinjo]

Hi @benyitzhaki,

First off, thanks for taking time to send us a PR.

I agree with @brian-brazil on this one. What's worth mentioning is that we did have a more flexible version of this that we removed pre-1.0. The reason we removed it wasn't that we disliked the feature, but that we felt the API was confusing. We would potentially be open to bringing that version back if the concerns in #111 were addressed.

I'm going to close this PR, but we'd be happy to hear suggestions on a more intuitive API for the version we removed in #121.