CLI to query for upstream server status?

1. Caddy version (caddy version):

2.3.0

2. How I run Caddy:

systemd, caddyfile

a. System environment:

Centos 8, systemd

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

test.dreamwalkers.dk { 
       
        reverse_proxy {

        to host1:8080
        to host2:8080
        health_path /foo/health
        health_interval 1s
        health_body "(OK)"

        }

}

3. The problem I’m having:

How can i query caddy for the upstream health status ? Like i would like to know if caddy see that both hosts in my config are UP

4. Error messages and/or full log output:

N/A

5. What I already tried:

curl localhost:2019/config/ but that will only give me the config, i would like to see the health status seen from Caddy, this could be a combined status from active + passive monitoring

6. Links to relevant resources:

N/A

That’s up to you to configure. You can set up a site on whatever port you want, and respond with a success.

:10000 {
	respond /health "OK"
}

Respond will make me an endpont to query, if Caddy are responding to http requests on port 10000, but it will not tell me the status of the reverse_proxy upstream hosts (host1 and host2). I am looking for a way to query Caddy for the current health status of the reverse_proxy hosts.

Ah, that’s not something that Caddy exposes currently; the proxy upstream pool is just maintained internally.

Best thing you can do probably is make a request to Caddy for /foo/health like your upstream seems to expose, and if there’s no available upstream, Caddy will serve you a 502, otherwise you’ll get a successful response. It’s as simple as that, really.

Got it … thanks!

I suppose the reverse proxy module could register an admin endpoint that exposes those details.

I feel it would be sorta funky to reference though, cause you might have multiple reverse_proxy handlers each with their own upstream pools. How would you uniquely identify the handler?

The upstreams are deliberately global, and are shared between handlers, because there is only ever 1 of any given upstream, even if multiple handlers refer to it.

Oh right – but still, how can you tell if any given handler is “healthy”, in the sense that all the upstreams it has references to are healthy, if there can be upstreams that are for other handlers, in the pool?

Think of a situation where you have handler 1 which has upstreams A and B, and handler 2 with upstream C. Upstream C is healthy, but both A and B are down. If you just look at the upstream pool, it would look like it’s healthy overall because C is healthy, but handler 1 is unhealthy because both its upstreams are unhealthy.

If a handler is a set of upstreams, you could just query the upstreams health and look at the ones you’re interested in, maybe? I don’t know if the concept of a “handler” being “healthy/unhealthy” makes a lot of sense though – it’s really just a combination of upstreams’ health statuses.

Matt, thanks for your input, yes basically for my use case, we want to make a query, and get all the upstreams health and look at the ones we are interrested in.

Alright @elsgaard :+1:

Could you type up a feature request issue on Github? Thanks!

Decided to take a shot at implementing it real quick, my interest was piqued. WDYT?

1 Like

Oh, awesome. That’s pretty much what I had in mind.

1 Like

It is exactly what we were looking for! I will test it during the next coming days and keep you updated. Great work! Caddy is a pleasure working with, we are currently building our new stack with Caddy replacing our existing webserver / reverse proxy.

3 Likes

Hi Francis

Can you guide me to build the latest caddy with your fix for the upstream status? I had hoped to build with xcaddy, but i can simple not figure out how to get master, i constantly get the 2.3.0 version :wink:

If you don’t need any plugins, then you can just grab the build from the CI artifacts here (scroll to the bottom)

Otherwise, when you build with xcaddy, you should specify a commit or tag as the first argument to build, so like:

xcaddy build [<ref>] [--with <module>]

To get a build right from the latest on the master branch with no plugins:

xcaddy build master

Omitting ref gives you the latest stable tag (i.e. v2.3.0)

This topic was automatically closed after 30 days. New replies are no longer allowed.