The healthchecks are configured not to cause load issues and I don't like another piece of clockwork that can muddy whats really failing. When the VIP HC is down and backend HCs are up that makes a clear picture quickly.
I'll likely code up a replacement HC in Python tomorrow. Will let the list know what we end up with. :) -J Sent via iPhone > On Oct 24, 2014, at 0:49, JCM <[email protected]> wrote: > > On 24 Oct 2014 03:18, "Jason J. W. Williams" <[email protected]> > wrote: > > > > How are folks deal with direct healthchecks (e.g. from Nagios) of > > backend servers that have PROXY protocol enabled? > > To clarify, you're healthchecking the backends from Haproxy, which copes with > the backends' expectation of a PROXY header just fine, but then want to > healthcheck the same services from $monitoring on the same ports? > > My choice of how to deal with this would be not to double-tap the backends. > Use the voluminous info exposed by the Haproxy stats interface to feed > $monitoring (including Haproxy's high-level idea of each backend being > available or not), and you might find that your backend availability goes up > due to lower load ;-) > > Personally, I like to feed the full complement of stats exposed into graphite > for troubleshooting, and then use that data store as $monitoring's single > point of truth. But I'm not sure how you'd achieve that flexibility in Nagios > land :-) > > Alternatively, you might use your backends ability to listen on a parallel > port which doesn't expect the PROXY preamble. I know nginx can be configured > in this way. > > Of course, you could "just" patch curl or wget to speak PROXY. Or cook up a > CLI-compatible, drop in curl-replacement python/ruby script in which you deal > with the connection below the level of the normal http libraries and teach > them the protocol. I've not seen either of those before - I'm sure the list > would be very happy to see your results! > > HTH, > Jonathan
