nginx-prometheus-exporter
nginx-prometheus-exporter copied to clipboard
Multiple nginx instances
Is your feature request related to a problem? Please describe. I am running a webhosting service with multiple nginx instances (one common for ingress and one for each hosted site).
Describe the solution you'd like It would be great if I can collect all the metrics with one instance of this exporter. Also, attaching labels for each nginx target would be nice.
Describe alternatives you've considered Run dedicated instances of this exporter and let prometheus to label all sources so I can differentiate between them.
Additional context
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 10 days.
are there are any updates on this? I can work on this if the maintainers believe we should do it. We also have multiple nginx instances deployed and would be ideal to run only a single instance of the exporter.
@aavshr I don't have any. I also considered to start working on it myself, but don't have much free cycles nowadays to proceed. Anyways, I am more than happy to test/review it if there will be a PR.
Hi @libesz sorry for the long wait for a response. From what I can tell this goes against Prometheus best practices. From https://prometheus.io/docs/instrumenting/writing_exporters/#deployment
Each exporter should monitor exactly one instance application, preferably sitting right beside it on the same machine. That means for every HAProxy you run, you run a haproxy_exporter process. For every machine with a Mesos worker, you run the Mesos exporter on it, and another one for the master, if a machine has both.
The theory behind this is that for direct instrumentation this is what you’d be doing, and we’re trying to get as close to that as we can in other layouts. This means that all service discovery is done in Prometheus, not in exporters. This also has the benefit that Prometheus has the target information it needs to allow users probe your service with the blackbox exporter.
Then it goes on about special cases like blackbox
but they use a specific pattern https://prometheus.io/docs/guides/multi-target-exporter/ that seems like a slightly different approach from the PR linked here.
So I'm not really sure about implementing this...what are the uses cases for this? Are you (or other people that liked and commented here) using other exporters that implement multi targets one way or another? I'm trying to figure what's the best way to handle this and if there's like a common pattern used.
If you use nginx as applicative router, you can have multiple instance on same vm, same docker. Actually, i deploy one instance by nginx, i have 4 exporter on the same docker machine. honnestly, i prefer deploy one exporter by docker machine, but is not mandatory, is not killing feature. (and thanks for your's works).
@lucacome Thanks for the details! Generally I agree with the dedicated instanceusage and the decomposition as much as possible with containers/microservices. The project where I would use this feature is a single-node web-hosting solution, where for example the HA requirements are not that hard. This single machine already runs 50+ containers for the sake of the proper isolation (runs dedicated nginx+fcgi workload containers of different web sites for security purposes). In this use-case, adding ~10 instances of the same specific exporter would not add much benefit, because the co-location to the app is already given and also the administrative domain is the same (web-site users does not really manage anything on the server).
I can accept if this is a marginal use-case and against the best practices. 👍
So I'm not really sure about implementing this...what are the uses cases for this?
In my case, I have HA nginx hosted on kuberentes managed by HPA. By requesting an nginx for metrics via kubernetes service, I request only one of the running instances of nginx at the time.
When setting up a ServiceMonitor, I can set a selector
field to specify which pods should be retrieved from cluster and requested directly by IP address (bypassing kubernetes service). In this way, I collect metrics from all app instances.
Well, my problem (described above) can be solved with deploying nginx exporter as sidecar inside the pod along with nginx.
I no longer see a valid point for implementing this feature in nginx exporter, so I'm taking back my "👍 "