Allow client to scrape a custom target while advertising a different FQDN

[mcastellini]

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.

[hansmi]

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]

@hansmi @mcastellini any information about possible merge soon?

[mcastellini]

@szaudowsky I rebased the PR against the latest master, though I have no idea if it will be merged soon.

[Liczi]

@brian-brazil @SuperQ are there any plans on a new release? Would it be possible to include this feature?

[roidelapluie]

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.

[josefzahner]

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.

[Liczi]

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.

[roidelapluie]

I have poked @SuperQ about this one. I still think this could be an HTTP parameter instead of a pushprox parameter.