PushProx vs. HTTP reverse proxy

[josdotso]

A good question for a FAQ:

What is the value add of PushProx over a common reverse proxy like nginx?

[SuperQ]

PushProx provides a service discovery endpoint to allow you to discover what targets are connected.

[saulp]

@josdotso , I'm honestly curious: how could e.g. nginx replace PushProx in a situation where the endpoints are not reachable from the Prometheus server? (Not being cheeky at all - just trying to understand)

[josdotso]

@saulp The reverse proxy would front the clients that are not reachable directly from the Prometheus server. The prometheus server itself would call the reverse proxy and the reverse proxy would handle the HTTP call behind the firewall or whatever -- just as if the /metrics endpoints were typical internet-facing via reverse-proxy webservers.

Thanks @SuperQ

[saulp]

Oh... I see -- you mean, run a reverse proxy in the same network as the client. Yeah, I don't think that solves the same problem that PushProx solves, since adding a reverse proxy parallel to the client is effectively opening incoming web communications, just with extra steps.*

The advantage of PushProx (in addition to the /clients endpoint SuperQ mentioned) is that it allows the use of the Prometheus pull model against clients that are within networks that (typically by policy and not necessarily due to technical constraints) do not allow incoming connections that originate from the outside world. In such a setting, a reverse proxy would not be allowed on the client end, just like access to e.g. the client's port 9100 is not allowed either.

PushProx runs on the server end. A typical use case is: monitor services within a satellite location that does not allow incoming connections from the web (say, a cheap Internet service that does not offer a public IP, and/or with a strict firewall policy), but that does allow web browsing. I don't see how adding a reverse proxy to the client network would help there.

* and yes, i realize there are several advantages of having the comms go thru a proxy instead of going to the exposed port directly (tls, ip whitelisting, etc), but the point remains that it would still require to enable/allow incoming connections and if you can do that, you don't need pushprox)