Am 26-12-2019 06:44, schrieb Willy Tarreau:
On Tue, Dec 24, 2019 at 10:29:44AM +0100, Aleksandar Lazic wrote:
I have created a feautre request for the check rewrite as we have more
more requests for checks which are quite difficult to setup.
Thanks for this. We definitely need to rework them for 2.2. At minima,
what I'd like to see, in order of realization:
- rewrite *all* health checks to internally use tcp-check sequences
so that we don't have to maintain this horribly broken mess anymore
can more easily implement new ones ;
Well, I think we will need also udp-check for example for DNS, QUIC and
- implement a new htx check mechanism that uses the muxes and that
able to seamlessly deal with H1/H2/FCGI, and likely plug onto idle
connections; these ones will need to support adding headers and
- implement centralized check definitions that can be reused in
backends. E.g. tcp-checks sequences or htx check sequences should
be defined once. This implies that some of the headers will likely
to support variables so that a backend may defined a host header
example and the checks use it.
But we have already such a possibility IMHO, it's the named defaults
If we can do all this it will be great.
Note that in your example above you're using %[host] for example,
the log-format syntax is only valid for traffic being processed, but I
get the idea anyway. For me it's the same principle as having variables
check parameters defined in the backend (or maybe even per server).
Yes, the log-format syntax was used to show that in some way a rewrite
variables will be necessary.
It would be nice to be able to reuse the feature
for the checks.
And you know there will be some distributed setups where the status from
should be shared with different haproxy instances, maybe via peers
will be maybe only possible in the commercial version ;-).