-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Undeprecate attributes module #50
Comments
The textfile module is a better way to do this, and we want to get rid of the config file. For example you can drop in a file to it with the content: |
That doesn't fo what I described. I want to know what the total used disk space is across nodes in cluster 'a', for instance, so I want the fs metrics to all have a cluster label. Your solution doesn't help with that. Also, I only have a couple of such labels, so putting them in a flag is fine. |
For that you need to configure that as target labels in the prometheus config, no feature of the node exporter can do that for you. Set |
Setting custom server-side labels only works for statically configured targets at the moment (that will change when we add more generalized SD support). What @swsnider suggests would add a separate set of time series that would contain attribute information about this exporter. These could be correlated via But yeah, there's currently no node exporter feature to just add a label to every time series exported, if that is what you want. |
These days we have both all the support needed to do this via the attribute approach, and service discovery in Prometheus would also allow you to do this in few ways including file_sd discovery. Setting target labels on an exporter is an anti-pattern we want to avoid, that concern belongs on the Prometheus server. |
I'm monitoring a set of aurora clusters. Because of how we move slave between them, the only source of truth for which cluster a given slave belongs to is a puppet configuration run, I need a way to annotate the metrics exposed from node exporter with that info -- it's not part of the metric uri that Prometheus saves for instance.
Is this module actually problematic for technical reasons? If so, is there a better way of doing this?
The text was updated successfully, but these errors were encountered: