Am 03.05.2018 um 18:18 schrieb Willy Tarreau:
>> Personally I'd prefer the rate limited warning over the counter. As
>> outlined before: A warning counter probably will be incremented for
>> multiple unrelated reasons in the longer term and thus loses it
>> usefulness. Having a warning_headers_too_big counter and a
>> warning_whatever_there_may_be is stupid, no?
> For now we don't have such a warning, so the only reason for logging
> it would be this header issue. It's never supposed to happen in theory
> as it normally needs to be addressed immediately and ultimately we
> should block by default on this. And if later we find another reason
> to add a warning, we'll figure if it makes sense to use a different
> counter or not.
> Also you said yourself that you wouldn't look at the logs first but at
> munin first. And munin monitors your stats socket, so logically munin
> should report you increases of this counter found on the stats socket.

So, definitely log + counter then, because counter alone IMO is a
debuggability nightmare. At least if you are not the person implementing
the counter.

>> I feel that the error counter could / should be re-used for this and
>> just the log message should be added.
> Except that it's not an error until we block. We detected an error and
> decided to let it pass through, which is a warning. It would be an error
> if we'd block on it though.


>> My munin already monitors the
>> error counts. The `eresp` counter seems to fit: "- failure applying
>> filters to the response.".
> If you see an error, you have the guarantee that the request or response
> was blocked, so definitely here it doesn't fit for the case where you
> don't block. And it's very important not to violate such guarantees as
> some people really rely on them. For example during forensics after an
> intrusion attempt on your systems, you really want to know if the attacker
> managed to retrieve something or not.


I'll see whether I manage to prepare a first stab of a patch this week.

Best regards
Tim Düsterhus

Reply via email to