-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify target labels for relabeling via /clients #85
Comments
Static labels can be added by prometheus itself at scrape time. |
Do you mean in a static config? I was hoping to use the |
It's an interesting idea about how to arrange labels in a reasonably consistent way to the
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. |
They would fulfill the same purpose as static A few other examples of tag meta labels I found are
|
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. |
@elliot-resdiary I have the same requires as your |
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 |
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 topushprox-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.The text was updated successfully, but these errors were encountered: