Hi,
On 17-11-21 14:20:39, Daniel Schneller wrote:
> > On 21. Nov. 2017, at 14:08, Lukas Tribus wrote:
> > [...]
> > Instead of hiding specific errors counters, why not send an actual
> > HTTP request that triggers a 200 OK response? So health checking is
> > not exempt from the
Hi Pieter,
>> Good point. I wanted to avoid, however, having these “high level” health
>> checks from the many many sidecars being routed through to the actual
>> backends.
>> Instead, I considered it enough to “only” check if the central haproxy is
>> available. In case it is, the sidecars
Hi Daniel,
Op 21-11-2017 om 14:20 schreef Daniel Schneller:
On 21. Nov. 2017, at 14:08, Lukas Tribus wrote:
[...]
Instead of hiding specific errors counters, why not send an actual
HTTP request that triggers a 200 OK response? So health checking is
not exempt from the statistics
> On 21. Nov. 2017, at 14:08, Lukas Tribus wrote:
> [...]
> Instead of hiding specific errors counters, why not send an actual
> HTTP request that triggers a 200 OK response? So health checking is
> not exempt from the statistics and only generates error statistics
> when actual
Hello,
2017-11-21 13:54 GMT+01:00 Daniel Schneller :
> However, I still wonder if there is a good way to discern these from
> “actual"bad requests in the stats, so that we can rely on the error counters
> to show “real” problems.
>
> Some kind of
Hi Lukas,
thanks — was just about to reply to myself, but you beat me to it ;)
> Yes, we have "option dontlognull" for that:
> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-option%20dontlognull
We can get rid of the logging via dontlognull, of course. Was about to mention
that
Hallo Daniel,
2017-11-21 10:08 GMT+01:00 Daniel Schneller :
> However, I see lots of 4xx errors counted on the central LBs. I have tracked
> those down to being caused by the health checks of all the sidecars,
> checking in every few seconds to see if their
7 matches
Mail list logo