Filtering Window Events

I have spent 4 hours looking at docs and trying various things. Under “Parameters for this service” I have tried to get it so that certain messages that I cannot fix under ‘Log Application’ and ‘Log System’ do not notify as critical events.

Tried ‘Disable notifications for services’ which will only disable notifications. Tried disabling active checks. Looked at docs.

I give up, how do you do it?

Hi @TexasDan,

you can use either the event console (little more complex, but more powerful Die Event Console - Logs und SNMP-Traps in Checkmk verarbeiten) or when you want to stay with classical log monitoring (also a valid approach :)) the rule you are looking for is called => Logfile patterns, where you can set events that should not be considered CRITICAL to OK or even ignore :slight_smile:


1 Like

Hi @TexasDan

welcome to the forum!

Gerd accidentally linked the German version of the guide, here’s the corresponding English version: The Event Console - Processing logs and SNMP traps

1 Like

Ok. Thanks.

I can see how to create RegEx and DROP messages I don’t want Event Console to process, but where is the Logfile Patterns that Gred mentions? Where is that found?

Hi Daniel,

you find this in the Setup menu, under Service Monitoring Rules just search for “logfile”

Gred -

I went into Event Console and practiced my RegEx with the tool there. I applied the Event, insured that it matched (green light) and applied it as a DROP rule, and the logs keep coming in and turning the hexagons red.

I couldn’t understand, so I applied the RegEx (.*) matching everything, set it to DROP and still, does not work. Do I have to apply Rule Packs in some special way? The documentation on this is unclear. Thanks.

Hi Daniel,

(it’s Gerd btw ;))

I think you might be mixing things up.

You either

a) use the EC and forward events from logwatch to the EC first, then you can drop events, but also need to build a rule for the other events.


b) use the logfile patterns as Elias suggested, in which case the EC is not used at all.



Apologies for the typo. I followed Elias method and put the wildcard (.*) into a Logfile Pattern, instructed that Logfile pattern to demote CRITICAL log messages from CRITICAL to IGNORE (just to see since it matched everything if it would work.)

I went into each host and did CLear log and waited. All the CRITICAL logs came back. The Logfile pattern was matching (for sure) but no IGNORE of the CRITICAL messages using this method either.

no worries :slight_smile:

would you mind sharing the full logfile pattern rule + the event if it’s nothing confidential :slight_smile:

Certainly. Here is the representation of the Logfile Pattern rule as REST API:

“{‘reclassify_patterns’: [(‘C’, ‘.*’, ‘Just Match ALL Critical and Ignore’)],\n ‘reclassify_states’: {‘._to’: ‘.’, ‘c_to’: ‘I’, ‘o_to’: ‘O’, ‘w_to’: ‘W’}}”

that means you reclassify all incoming CRITICAL to Ignore, but then your regex reclassifies “.*” to CRITICAL.

so either change the state before your regex to “.*” or simply only use “reclassify complete state” :slight_smile:

Yes, that worked. Thank you, Mr. Stolz. I see now how it works.

I can only imagine that each and every customer should like to baseline their Windows hosts and filter down the CRIT messages that they cannot prevent from occurring, to baseline what is normal and abnormal CRIT errors that require response. I should hope this is helpful to others.

agreed - I don’t know a single installation that collects and acts on all windows event log entries

@mschlenker is that a Documentation topic or maybe even a default rule that could be added to new installations?

Hello Gerd (or anyone),

I am seeing that under:
Setup > Services > Service monitoring rules > Logfile patterns > Logfile pattern analyzer

That the Logfile pattern analyzer caps out at 49 RegEx. I don’t see that in the documentation. I have created about 80 expressions but I can see that ones above 50 do not match. Have I done something incorrectly?

Sounds like a bug - possibly only in the log analyzer GUI.

Can you reproduce this on a current 2.3? Then I would suggest raising this as a support case :).

Yes, this is on 2.3. I will file it as a bug. Not only does the logfile analyzer cap at 49, but the whole system does as well. None of the RegEx past 49 match and filter, I had asked them to move them to IGNORE. It stops after expression 49.