Open hatchan opened 1 year ago
The Pros seem compelling.
Could you elaborate on the con of rewriting the path? (What makes that a con specifically?)
And for the "/pushgateway/metrics" issue: Is there a world where we could map all POST requests to /metrics
to the pushgateway? Or is that messy to implement?
Could you elaborate on the con of rewriting the path? (What makes that a con specifically?)
Might be more of familiarity of current users. If let's say you have some other tools that need to interact with Prometheus, but you expect prometheus to run at http://localhost:9090/ then it won't work. Since then actual endpoint is http://localhost:9090/prometheus/.
And for the "/pushgateway/metrics" issue: Is there a world where we could map all POST requests to
/metrics
to the pushgateway? Or is that messy to implement?
That is a good idea :+1: . If the pushgateway is enabled, we can indeed proxy those POST calls. See https://github.com/autometrics-dev/am/issues/63
Currently we are running prometheus and pushgateway on a specific port, and we are also forwarding the content using the listen address of am +
/prometheus
. This requires us to specify the web-address as a config to either components. The downside is that the origin then uses the new path in the prometheus web server. Which can be confusing for a user since they need to forward their metrics tolocalhost:9091/pushgateway/metrics
which can be confusing.Pro's of proxying:
Con's: