Allow adding arbitrary labels to metrics when generating output

[willnewton]

It's useful to be able to apply a label across all metrics, for
example when using a multi-processing framework to apply a
label for worker ID to all metrics (including from builtin
collector types). This change adds a new Registry type that
applies a dictionary of labels when metrics are collected.

Signed-off-by: Will Newton will.newton@gmail.com

[csmarchbanks]

Hmm, so this is a bit backwards of what I was imagining, I apologize for not being clear in the other comment/misunderstanding your goal. The use case I would support is what is described in client_golang/prometheus#WrapRegistererWith. This allows systems such as distinct workers to register the same set of metrics with a distinct label, but would not apply to every metric being exported. For more details on why we don't encourage labels on every metric see https://prometheus.io/docs/instrumenting/writing_exporters/#target-labels-not-static-scraped-labels.

Does that make sense/would it help your use case?

[csmarchbanks]

This example is incorrect as it should be passing a dict of constant labels.

[Sircular]

@csmarchbanks I'm a little confused by your comment, since the Python client doesn't seem to have the concept of a Registerer like the Golang client. Is the idea that we would create a wrapper class that contains a Registry which augments the labels of a collector when .register() is called? Then we could make multiple wrappers that add different labels, and they could all reference the same registry.

[csmarchbanks]

I can imagine a few implementations that would be acceptable, but my guess is that we will have a new class that inherits from CollectorRegistry but overrides collect() to add the labels to each metric as they are yielded rather than adding labels to the collectors. You could then do something like:

REGISTRY.register(labeled_registry)

to add all of the labeled metrics to the default registry or any other registry. Does that make sense?

I might even be ok with just adding a const_labels variable when initializing a CollectorRegistry, but not sure if that would be best compared to a new class.