-
Notifications
You must be signed in to change notification settings - Fork 342
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 few development ideas #28
Comments
@kworr thanks for you suggestions! Regarding No. 1 - makes sense. Regarding No. 2 - I'm not sure I fully understand the benefits of scraping multiple hosts at once from your example. |
I have a few geographically separated hosts that I want to scrap. This means I can't expose exporter as I need HTTPS/Auth over internet. Currently the stack looks like:
When exporter would be able to scrape more then one server this can be transformed to:
Simplifies delivery curve a bit and makes it a lot easier to deploy. |
@kworr thanks for further clarifying your case. scrapping all the hosts in one exporter will complicate the implementation and configuration of the exporter. Additionally, such an exporter will present a single point of failure -- if it fails, the Prometheus will not be able to scrap the metrics of all the NGINXes. |
Thank you! |
nginxexporter_build_info metric is available in 0.3 https://github.com/nginxinc/nginx-prometheus-exporter/releases/tag/v0.3.0 |
Hello.
Just took a quick look on it and deployed over my hosts. There's a few things that might add to the value:
It would be nice to have _build_info. Currently I can't get exporter info on the board to plan tiered upgrades.
It would be nice to be able to scrape multiple hosts. With HTTPS/Auth nginx is already an external service that can be used to transfer data. This will also make it possible to transport data securely over network. For example, if I have a few hosts in different DCs I need to proxy exporter via nginx for example, if exporter would support scraping more then one host, authorization and HTTPS it would be possible to expose /stub_status on nginx externally in a restricted location. This will make provisioning easier.
The text was updated successfully, but these errors were encountered: