See original question response here: Check_mk Windows Log : Checkmk
That response mentioned the fantastic video here:
But I wanted to include a bit about the rules I use. I setup an EC rule pack with rules per Windows log. So the syslog tag matches the log type, in this case the Windows System event log. I use the Windows CG as my way of figuring out the “who”, but perhaps better in the notification step a bit later. The key here is the addition of the “Windows Event” comment, I’m going to key off that for bulking the Windows messages as an email notification (that way with one notification rule I can capture the things to bulk for email for all Windows event things as long as they use the magic comment mentioned above and seen in the image attached). Note, this means Windows events to the console stay around for 3 hours. We’re just trying to keep the event console from filling up. Since we notify (below) via bulk, long term collection is up to the receiver with regards to how long they want to keep their bulk emails. Windows events are much like “crying wolf”, even when legitimate. You can feel free to adapt to however you want to work. For us the screams of Windows are best left to bulking and glancing over (but you can certainly tune, and we do, to filter completely out (drop) the biggest cries and notify more immediately on real things, and we do have a catchall for things we’re not handling specifically (things for which we need to add rules for)).
For a notification rule, again key’d off the Windows Event magic comment and going via email to Windows CG folks. Bulked. We also have notification rules (not shown) to feed these as they happen into our “firehose” via Microsoft Teams.
Hope this gets people started on at least an example way of dealing with Windows Event logs.