Repository navigation
Specify target labels for relabeling via /clients #85
Description
The /clients endpoint's labels field would be the ideal way to provide static target-based labels for relabeling metrics. Our use-case requires each scrape target to have an environment, region and component tags which are crucial when we're using these metrics.
If we could add a --labels argument to pushprox-client that would be perfect for us. What do others think? I haven't used Prometheus for long so maybe there's a better way to do this, though I'd be glad to raise a PR for this if others also would like it.
Activity
roidelapluie commentedon Jun 22, 2020
Static labels can be added by prometheus itself at scrape time.
elliot-resdiary commentedon Jun 22, 2020
Do you mean in a static config? I was hoping to use the
/clientsendpoint to discover targets along with the labels required to make their metrics useful.SuperQ commentedon Jun 22, 2020
It's an interesting idea about how to arrange labels in a reasonably consistent way to the
/clientsdiscovery interface. At the same time, avoiding arbitrary cardinality issues.There are few different options here. Without a detailed conversation about your overall architecture, and design use case for PushProx, it's hard to say. But that's not really a conversation to be had over an issue.
elliot-resdiary commentedon Jun 23, 2020
They would fulfill the same purpose as static
__meta_*tags which are available with the other service discovery mechanisms. Originally we were planning on using__meta_azure_machine_tag_<tagname>before realizing we needed PushProx to traverse NAT.A few other examples of tag meta labels I found are
SuperQ commentedon Jun 24, 2020
If this is an Azure deployment, you should be running Prometheus inside of your VPCs to avoid NAT issues. Prometheus is meant to be distributed and deployed inside networks. PushProx is meant for more IoT use cases.
cycwll commentedon Jul 3, 2020
@elliot-resdiary I have the same requires as your
Eagleseb commentedon Jun 16, 2022
I agree this would be really nice to have, I could maybe have a look at the code base to implement that if someone could give me pointers
moreinhardt commentedon Jan 19, 2026
I just saw that
/clientsreturnslabelsand thought that I must be able to configure these exactly like proposed in this issue when starting the client, e.g. withpushprox-client --label exporters=node,zfs --label foo=bar.I have a very simple use case here, which is exactly what's asked about in #160:
Not all targets have all exporters running. E.g.
nodeis running on all hosts, butpostgresorzfsonly on some. In the dynamic scrape config for network-internal hosts I use cloud provider tags to filter the hosts in therelabel_configs. Now I want to do exactly this with the hosts that can only be reached via pushprox.Atm I have separate jobs for every exporter accessed via the proxy with static target configs.
Would be really cool if this could be added. Would you be open to reviewing a PR that adds this, @SuperQ?