prometheus-community
Allow client to scrape a custom target while advertising a different FQDN
Some use cases might require exposing a given FQDN while targeting a different host name.
This is quite visibile when using a containerized version of the PushProx client to scrape an instance inside a docker-compose based deployment: if multiple instances of such deployments are referring to the same PushProx proxy, they will end up POSTing the same FQDN in /poll (e.g.: node-exporter), which in turn leads to naming clashes at proxy component level.
This PR allows to specify a --target option so that one would be able to specify a given FQDN while in practice being able to scrape an internal target without needing to worry of potential naming clashes at proxy level.
LGTM. I had a similar case where FQDNs resolve to a host's external IP address (e.g. 192.0.2.1), but exporters listen only on 127.0.0.1/::1. The solution was to bind-mount a custom /etc/hosts file in my Pushprox service instances.
@SuperQ FYI
@szaudowsky I rebased the PR against the latest master, though I have no idea if it will be merged soon.
@brian-brazil @SuperQ are there any plans on a new release? Would it be possible to include this feature?
I am wondering if that should be a feature given that Prometheus itself does not support that. And also I wonder, if the maintainers of this repo want it, if that should be a request parameter instead.
Where is the problem that this PR hasn't been merged yet (since several months)? There are a few lines of code which has been modified. We really need this feature of setting the FQDN manually by a parameter as our raspberry pi's have issues with identifying the FQDN correctly. It's really unpredictable what they choose and requires a lot of fiddling. And we have cases where we don't know the domain name. So to make a long story short, it's very important that we can configure the FQDN manually with a parameter.
More than that, it makes monitoring of docker services harder as they use service name as an FQDN inside the docker network. It basically forces us to use network_mode: host even though the push-proxy could work as a docker container and use internal addressing.
I have poked @SuperQ about this one. I still think this could be an HTTP parameter instead of a pushprox parameter.