-
Notifications
You must be signed in to change notification settings - Fork 235
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
A way to disable go, statsd_exporter and prometheus metrics #446
Comments
These can be dropped using metric relabel configs. For questions/help/support please use our community channels. There are more people available to potentially respond to your request and the whole community can benefit from the answers provided. |
At the moment there isn't. I would be open to it in principle, but only if there is a really good use case that cannot be satisfied otherwise. It is possible to run into conflicts between translated and internal metrics, but so far this has always come down to someone trying to build a push metric system by [looping Prometheus metrics through another protocol](https://github.com/prometheus/graphite_exporter/issues/165#issuecomment-922747805]. What problem are these causing for you? |
I'am using statsd_exporter in a sidecar container in my kubernetes deployment for airflow metrics collection by ServiceMonitor. |
Would it at least be possible to add custom labels to them (so they will end up on the appropriate service dashboard in my case)? I might be using it wrong, but the following mapping file does not seem to affect the built-in metrics: mappings:
- match: ".+"
match_type: regex
name: "$0"
labels:
group: my_service_group
instance: my_service_name |
Not really, we don't have influence over the metrics generated by the Go client. Generally, the Prometheus approach is to not have a service "identify itself" like this; this is a job for service discovery (and if necessary, relabeling). I would also recommend deploying the exporter as a sidecar and considering it as part of the service that sends metrics to it; this way you don't have to transport service identity through statsd events and mappings. If this isn't an option, use the |
Yeah you make a good point about not self-identifying services. Prometheus knows which service it's scraping and so there's no value in putting that responsibility on the applications. |
Hello!
Is there any way to disable these metrics?
The text was updated successfully, but these errors were encountered: