Introducing backend healthchecking plugin
work at anomalizer.net
Wed Mar 3 05:47:39 MSK 2010
On Mar 02, Piotr Sikora wrote:
>> 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
The only philosophical objection I have to this style is having
something to do on the LB servers to change and upstream status. I
wanted a facility wherein something can be done on the upstream server
(rm the health check file) to remove it out of service.
I come from a world wherein any sort of access on the LB servers is
tightly controlled and the people managing the upstreams (application
servers) can plan a maintanence without ever involving the LB folks.
Am also not a fan of the supervisord_start/supervisord_stop directives
since managing the security aspects of it becomes a hassle.
I am however a fan of supervisord_inherit_backend_status which is why I
wanted to integrate it with the health-check plugin :-)
More information about the nginx