#Raised to Warning, Web log unparsed = 1.14 %, on xxxxx

1 messages · Page 1 of 1 (latest)

stark dust
#

Hi! I have one server i particular (a matomo server) which netdata quite frequently warns about "web log unparsed". And, after a while the warning resets and it's 0%. Why does this happen, and is there a way to tune this? The web logs for this server are massive (as expected, it is a web analytics system)

stark dust
#

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

plain hemlock
#

I have the precisely the same issue

cinder flax
#

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 warn threshold)
  • 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.

grim badger
#

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”.

Netdata Community Forums

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...

cinder flax
cinder flax
#

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

grim badger
#

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.

cinder flax