Issue Details
Add a small set of Prometheus metrics for the reverse_proxy roundtrip path, labeled by upstream so they line up with the existing caddy_reverse_proxy_upstreams_healthy gauge.
Today, the reverse proxy only exposes upstream health. There's no built in visibility into per-upstream request rate, in-flight concurrency, or latency. We can't answer "how is this upstream performing" which is what we want when load-balancing across many backends.
I propose having four metrics:
- caddy_reverse_proxy_upstream_requests_total{upstream}
- caddy_reverse_proxy_upstream_requests_in_flight{upstream}
- caddy_reverse_proxy_upstream_responses_total{upstream, code}
- caddy_reverse_proxy_upstream_duration_seconds{upstream, status}
I have a branch ready implementing the above. Happy to open the PR if this sounds good.
Assistance Disclosure
AI used
If AI was used, describe the extent to which it was used.
The feature idea is mine, but Claude helped draft the proposal text
Issue Details
Add a small set of Prometheus metrics for the reverse_proxy roundtrip path, labeled by upstream so they line up with the existing caddy_reverse_proxy_upstreams_healthy gauge.
Today, the reverse proxy only exposes upstream health. There's no built in visibility into per-upstream request rate, in-flight concurrency, or latency. We can't answer "how is this upstream performing" which is what we want when load-balancing across many backends.
I propose having four metrics:
I have a branch ready implementing the above. Happy to open the PR if this sounds good.
Assistance Disclosure
AI used
If AI was used, describe the extent to which it was used.
The feature idea is mine, but Claude helped draft the proposal text