Page Comparison

...

Getting Started

Background information regarding this subject is available on our:

• Official documentation
• YouTube Video

Checkmk Rules needed

Configuring the Checkmk Agent

...

Setup→ Agents → Windows, Linux, Solaris, AIX → Agent rules → Finetune Windows Eventlog monitoring → Add Rule
Image Modified

After saving this rule, activate the changes and bake & sign your agents.

...

Setup → Services → Service monitoring rules → Logwatch Event Console Forwarding → Add Rule
Image Modified

We recommend using the spooling, so the events are buffered if the Event Console should be down for a moment. The syslog facility "local1" can be used later in the EC rules for efficient event handling.

...

From now on, the events from the Windows Eventlog on your hosts will be translated to Checkmk Event Console events and put into the event archive (if not matching any EC Rule yet):

Image Modified

We will create some EC Rules in the next paragraph to categorize and classify the incoming events. Using the message texts from the Event History, you can define the needed Regex patterns for that.

Creating the Event Console Rules

Basic Rules

...

1. Create a Rulepack with a suitable name:
   Image Modified
   
   
2. Go to the rules of this Rulepack

...

1. 
   Image Modified
   
   
2. There, create a rule to handle all events that

...

1. do not

...

1. match any other rules yet

...

General properties

Setup → Events → Event Console rule packs → Add Rule
Image Modified

Matching Criteria

Here, we need two regular expressions:

Image Modified

1. The first one is applied to the message text and defines three matching groups using the brackets:
   
   

   Code Block
   language bash theme RDark
   .{3} [0-9]+ [0-9:]{8} [0-9]+\.([0-9]{4}) ([^ ]+) (.*)

   
   

   The website https://regex101.com helps you to understand how the regex matches the message text and which groups are created:
   
   Image Modified
   
   These groups can later be accessed using the placeholders \1, \2, and \3 in the message text rewriting. They might also become important when automatic duplicate detection is used. We'll come to that later on.
   
   
2. The second regular expression "^(.*)$" simply matches on any Application text (in our case, it's always "Security", though) and puts it into a matching group. Later, we can access this group using the macro "$MATCH_GROUPS_SYSLOG_APPLICATION_1$".

...

The "Outcome & Action" section can remain unchanged, but in the Counting & Timing, we have two definitions:

Image Modified

The counting is done based on the hostname and the application. Forcing separate events for different match groups makes no sense here because the message text is stored in group 3, and as we all know, these texts sometimes contain IDs, timestamps, and similar unique strings.

...

In the Rewriting section, we can adjust the message text, application, and other variables that will be shown in the event views:

Image Modified

The message text will be replaced using the groups from above:

...

WinEvtLog_Unknown_Security_4799

Conclusion

Using this "unknown" rule, we will catch all so-far not categorized events, adjust their message text and application, and then aggregate ("count") them based on the hostname and that modified application.

...

Clone the "unknown" rule and modify the following fields:

Image Modified

The Regex

Using the long message text, we pick out the important information (colored) and create a regular expression pattern, starting with the one we already used in the "unknown" rule:

...

Fill in the new pattern in the "Text to match" field:

Image Modified

Counting & Timing

The counting and timing also will be changed a bit:

Image Modified

For this kind of event, we want separate events if the match groups ("executing user name" and "affected user name") are different.

...

In the rewriting section, the texts are also adjusted to the newly defined event:

Image Modified

Further Rules and Performance Considerations

We have to create further specific rules as done in the last steps. Here are some things you have to take care of:

• The first rule that matches will handle the event. All upcoming rules will not be checked at all. Thus, the order of your rules is important. The most common rule (in our case, the "unknown" rule) has to be last.
• Some rules might be moved up and down independently because they have an explicit pattern or other conditions defined. In that case, put those rules that are used most to the top. This will increase your "rule hit ratio" and, thus, the performance of the Event Console.
• To further increase the performance, place a dropping rule on the top of your list that drops all events that don't match the syslog facility you have defined in your forwarding rule.
  
  

After that, your rule pack should look similar to this:

Image Modified

Testing these rules by creating and deleting a user on the monitored host results in the following events:

Image Modified

To get rid of the "unknown" events in-between, we can do two things:

...

• Create a view that filters out all events coming from the Rule with the ID "WinEvtLog_unknown"

...

...

• Disable the rule "WinEvtLog_unknown", so those events will be dropped (or archived).

Related articles

...