#Raised to Warning, Web log unparsed = 1.14 %, on xxxxx
1 messages · Page 1 of 1 (latest)
I am still looking for assistance on this. I am not sure how to tune this warning, or if I should just permanently mute it and treat it as false positive
I have the precisely the same issue
Guys, this is % of log lines weblog (collector) failed to parse. You can check Netdata logs to find out what log lines these are: grep "unmatched line".
You have 3 options:
- Ignore this alert.
- Adjust this alert (increase
warnthreshold) - See if it is possible to adjust weblog's parsing pattern.
Probably there is a bug, we need to see what lines it was able/wasn;t able to parse.
I’ve asked about something related in the community: https://community.netdata.cloud/t/can-web-log-be-configured-to-ignore-certain-lines-to-avoid-mismatch-alerts/4805
In my case, being able to set a pattern for log lines that should be simply ignored would solve the problem of erroneous alerts… and the case where web_log fails to start when the most recent log line happens to be a “bad request”.
I have configured web_log to parse logs from HAProxy (which is configured to log in its httplog format) using a custom regexp log type. Everything is working fine, except that I am frequently receiving web_log_1m_unmatched alerts because of how HAProxy logs various “error” events. Even though my regexp pattern does parse this error-line varian...
and the case where web_log fails to start when the most recent log line happens to be a “bad request”
It reads most recent 100 lines and fails to start if none are parsable
In my case, being able to set a pattern for log lines that should be simply ignored would solve the problem of erroneous alerts
I think we could add an option to ignore log lines
It reads most recent 100 lines and fails to start if none are parsable
Is that a recent-ish change? (I swear it used to fail to start if the last log line wasn't "parseable".)
I think we could add an option to ignore log lines
Being able to define pattern(s) that cause the line to be ignored would be useful since it would prevent "false" alerts.
I swear it used to fail to start if the last log
It used to work like that, you are right. But I changed it long time ago (Jan 4 https://github.com/netdata/go.d.plugin/pull/1454)