Service discovery is the responsibility of Prometheus

https://github.com/siimon/prom-client#default-labels-segmented-by-registry indicates that this library has functionality to allow setting target labels. This is an anti-pattern in Prometheus as that's the role of service discovery/relabelling, and a client library should not facilitate this anti-pattern. This functionality should be removed.

It came from #83 (feature request) and #137 (PR), cc @goofballLogic @nwest1 thoughts?

Thanks for the mention -

Bottom-line, this simplified the code necessary to emit metrics. If it was removed, it would mean more complexity and repetition in our own code, and no (easy) ability to label default metrics in a way we would expect.

Due to timelines/prioritization this was a feature we found useful - especially when not having access to modify prometheus config.

Would a note about the recommended approach be sufficient here without a full removal?

Would a note about the recommended approach be sufficient here without a full removal?

This is such a common misunderstanding of the Prometheus architecture that it should be removed. You should switch to relabelling for this.

I would like to point out that there is a legitimate use case for using prom-client's default labels feature:

When using node cluster node, it can be used to apply a "worker" label with the worker id. This cannot be done outside of prom-client using regular prometheus relabeling.

All of the official prometheus client libraries are for languages that are multi-threaded (rather than multi-process), so they don't need this feature.

The Python client's multi-process mode handles this internally. Instrumentation shouldn't have to care how exposition is done.

The Python client's multi-process mode handles this internally. Instrumentation shouldn't have to care how exposition is done.

I would be happy if prom-client would also handle this internally and automatically :+1:

Is there support for the multi-target pattern in this library? It doesn't seem like there's any way to pass parameters into exporters with this client, and that can be a blocker for certain setups