On 9 September 2011 13:29, Graeme Donaldson <[email protected]> wrote:
> > Hi John > > The "something odd" you are doing is attempting to use the httpchk > option to speak a non-HTTP application protocol. > > Using the "check" option in server definitions will make HAproxy check > if it can successfully establish a TCP connection to the IP/port for > the server. Successful connection == successful health check. There > isn't a way to send a specific command to the application (INFO in > your case), nor parse for specific reponse/s. > > Using "option httpchk" allows us to do smarter health checks when a > backend is speaking HTTP. It sends a specifically crafted HTTP > request, and HAproxy will expect responses with specific HTTP response > codes. This can be further fine-tuned using "http-check expect ...". > > Unfortunately, redis does not speak HTTP, and thus you cannot use > "option httpchk" or "http-check expect ..." with it. Your health check > options are limited to testing TCP connectivity to the IP/port of each > server. > > Regards, > Graeme. > Hi Graeme, Indeed, the httchk is expecting a HTTP response header. I think I can fool it by installing a wrapper script on the target which inserts a valid HTTP response header - there is an example of that at http://sysbible.org/2008/12/04/having-haproxy-check-mysql-status-through-a-xinetd-script/ Thanks for the info John -- John Helliwell
