Log file Patterns - OOM alerts do not clear on next check

CMK version: 2.5.0p9
OS version: Red Hat 9.7

I am using log file patterns rule to alert on OOM. I am testing it using the logger command. It is alerting but not clearing on the next check. Google search says the rule page should have a checkbox labeled “Do not store log messages in the status output” (or “Clear text after read” depending on your exact version patch) and check it. Neither of these options are in the rules page in v2.5.0p9 community edition?
I also tried enabling the “Reclassify complete state” and setting change critical/warning/ok to OK but didn’t make a difference, so I left it unchecked.
Thanks


That is a nice AI halluzination :smiley: , you can only clear the alarm if you acknowledge (delete) the events after you opened the log file inside your CMK gui. (typewriter symbol)

2 Likes

Thanks Andreas, it even suggested if I couldn’t see either option it is because I have my profile set to not show advanced options. I have been chasing my tail all day. Having said that, the hallucination sounds so logical, maybe Checkmk can include it in a future version :slight_smile:

I also have a related question. I deployed the mk_logwatch.py plugin to the monitored hosts along with the /etc/check_mk/logwatch.cfg that contains the following lines. Seems redundant that I had to also still provide the regex in the rules I create in the WATO?
[ ~]$ cat /etc/check_mk/logwatch.cfg
/var/log/messages
C [Oo]ut of [Mm]emory
C [Kk]illed process
C oom-killer

If you configured your logwatch config like it is shown, then you don’t need to configure any patterns inside WATO/Setup. The pattern there are only needed for events that you want to rewrite in criticality, like Windows events logs that are warning and you want to see it as critical or critical events that you want to make ok. As the title of you rule states “Reclassify …” it is only used to rewrite the event.

1 Like

To the best of my knowledge, the automatic reset of events is a feature of the Event Console, although I could be mistaken, as I use the Event Console exclusively for all events.

In general, I would recommend forwarding such events to the Event Console, as it provides significantly more flexibility. For example, you can configure the event lifetime to control how long an event should remain active.

For an event in the Event Console to be automatically cancelled by an OK event, the corresponding OK event must first be defined in logwatch.cfg so that it is forwarded to Checkmk. This definition is currently missing in your logwatch.cfg example.

Afterwards, you can configure an Event Console rule that specifies which event should be cleared by which OK message.