Willy, 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. Understood. >> 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. > Understood. I'll see whether I manage to prepare a first stab of a patch this week. Best regards Tim Düsterhus
