On 2009-12-24 10:22, Willy Tarreau wrote:
[ forgot to CC Krzysztof ]
On Wed, Dec 23, 2009 at 11:27 PM, Willy Tarreau <[email protected]> wrote:
On Wed, Dec 23, 2009 at 10:52:52PM -0800, David Birdsong wrote:
this can be dropped for now. it turns out that twisted doesn't
actually return error codes when you instruct it to. it puts the
error codes in the xml response for code to deal with but slaps a http
200 in the headers.
so we really need a working regex-based health check :-/
Willy
i've had coworkers complain about health checks only looking at http
response codes.
i'm undecided. i think it's reasonable for proxies/load balancers to
work at the protocol level, but i've definitely been hamstrung by it
when working with libraries that don't always provide access to the
protocol levels without combing through and learning the entire
library.
Other people need to ensure that a specific tag is present (or is not
present) in a given page. For instance, it can make sense to kill a
server which reports SQL errors in the HTML code.
how hard would that be to add?
It's not that hard and it has already been done once, but the code contained
various issues and bugs which need to be fixed. After some review, it appeared
that it would be easier to re-implement it (possibly keeping some parts of the
patch) than auditing it completely and fixing the remaining issues. If you
want to work on something like that, please first check with Krzysztof (CCed),
because he regularly works on stats and checks and I would not be surprized if
he already had some pieces of code in good shape.
Not this time. ;)
The code I have currently is only a fast-hack to help my "IIS
colleagues" by extracting IIS "extended http codes" provided in the
html, so they are able to track malfunctions faster. However, I believe
it would be quite easy to make it more generic, mainly by adding a
proper configuration interface and allowing to fail a check, not only by
a http response code, but also by a matched/unmatched regex (slower) or
by a found/missing string (faster).
I think I should be able to publish a first RFC patch at the beginning
of the next week (~11.01.2009), so after 2-3 interactions it should be
ready to be merged. If you are still going to accept such changes after
the 1.4dev5, it should get into the 1.4 release.
Best regards,
Krzysztof Olędzki
