Introducing backend healthchecking plugin
piotr.sikora at frickle.com
Wed Mar 3 01:10:41 MSK 2010
> The second style is needed in cases where we plan to do some maintanence
> activity on an upstream server and want to proactively not send traffic
> to it. Typical example is when you want to push new software, check with
> a couple of requests and see if your app is behaving well and if all
> looks fine, direct traffic to it.
Actually, you don't need health-checks for that, ngx_supervisord provides
that functionality out-of-the-box. If you plan on taking servers down for
maintenance, you can use supervisord_stop and supervisord_start handlers.
Please take a look at example configuration #2, because it does exactly
> In the absence of priority between the two styles of checking, we could
> end up with a flapping upstream status. The logical priority seems to be
> that #2 wins over #1. So, if the health check url says an upstream
> server is down, no traffic should be sent it way and the health status
> evaluation based on style #1 should be ignored. If the health check
> deems and upstream to be up, then the outcome of #1 is the final status.
In-line checks are considered failures. When you take down server with
ngx_supervisord, it's marked down (same way as if you would add "down" in
your configuration and reload nginx), so it takes priority.
> I will not have time before this weekend to get started on merging
> these; so if someone gets down to doing it earlier, thanks :-)
I'll try to find some time today, can't promise anything though.
Piotr Sikora < piotr.sikora at frickle.com >
More information about the nginx