Windows Event Log Monitoring
LogicMonitor can detect and alert on events recorded in most Windows Event logs. An EventSource must be defined to match the characteristics of an event in order to trigger an alert. When a collector detects an event that matches an EventSource, the event will trigger an alert and escalate according to the alert rules defined.
Note: LogicMonitor does not currently support the monitoring of any logs located under the "Application and Services Logs" folder in the Windows Event Viewer snap-in console, as these logs aren't natively exposed to WMI. If you would like to monitor your Application and Services Logs in LogicMonitor, you can use Microsoft Subscriptions to 'copy' logs from your Application and Services folder to another log folder (e.g. Application logs).
You can define a new Windows Event Log EventSource from Settings | LogicModules | Eventsource | New | Eventsource. Set the Type to Windows Event Logging:
- Applies To associates an EventSource with a device or set of devices. See here for more details. In the example above, isWindows() means the EventSource will be associated with any Windows devices.
- Group (optional) allows you to group several EventSources in a folder.
- Filters define the set of characteristics that events must have in order to trigger an alert. You can filter based on the alert event ID, level, log name, message, and source name. An event must satisfy every line in the Filters section. In the example above, the Event ID must equal 7040 AND the string 'disabled' must be in the event message.
- Alert Settings define the characteristics of the alert that is triggered when an event is detected that matches the filter criteria for this EventSource. Note that by default, LogicMonitor maps Windows severity levels to LogicMonitor severity levels (e.g. Error to Error, Critical to Critical). You can override this default mapping so that LogicMonitor alerts triggered for particular Windows EventSources have a different alert severity than the Windows alert level. To do this, change the value of the ‘Alert Level for Matching Events’ field for a Windows Eventsource, as shown below:
Note: LogicMonitor's default Windows EventSources have a filter that only alerts on Error and Critical level events.
Effective Interval defines the period of time (in minutes) that an alert should last after an event is detected. For example, given an Effective Interval of 60, an event such as system restart will show as a current alert for 60 minutes after the event is detected. This permits time for the alert to be escalated. After the Effective Interval has expired, the device will no longer be in alert from this event. (Of course, the alert will be visible in the alert history, and will have been sent according to applicable escalation rules already.)
Alert Message is the content that will appear in the body of your alert, it will override the default EventSource alert template. Any of the EventSource tokens can be included.
Event ID Filtering
To match multiple event IDs, you can use the In comparison operation, and list the event IDs separated by the pipe "|" character - spaces are ignored. For example:
- Each line in the Filters section is combined using a logical AND with the other lines, so adding more lines makes the filter more restrictive.
- Windows Event Log uses the same event level for both error and critical events reported through WMI. Ensure that you take this into account when choosing the alert level for routing. Selecting anything over warning will catch both error and critical events. Critical events route the same as error events and are also designated as error-level alerts in the LogicMonitor console.
- Regexmatch should not be used - use the In operator instead.
- RegexNotMatch does not support regular expressions - it only supports a bar separated list of eventIDs to exclude.
- By default, LogicMonitor excludes all events of level Informational. Thus if you specified a filter of Logname equals System, with no other filters, you would see all events except those of informational level. In order to raise alerts on Informational level events, you must specify the event explicitly by ID using the EQUAL or IN operator.
- In some cases, a resource's Windows Event Log will generate an event without populating the INSERTIONSTRINGS attribute of the message. This may result in LogicMonitor capturing an event with a matching EventID and generating an alert, passing along the null value read from the host side. You can add a filter into the EventSource to discard messages that the resource generates incorrectly:
You can use the ##FILTEREDEVENTS## token to filter event Ids based on the value of the FILTEREDEVENTS property set at the device, device group, or global level. Consider the following EventSource filters:
The first three lines in the Filters section above will find all events in the System Event log with a severity greater than warning, excluding events with EventIDs 1111 or 10009 . The fourth line (boxed in red) will then exclude events where the EventID matches the IDs contained in the ##FILTEREDEVENTS## property.
- You can set the FILTEREDEVENTS property to exclude events. This property can be set on the global, group, or device level for granular control.
- Initially, when the FILTEREDEVENTS property has not yet been set on any device or device group, it is an empty string, and so does not match (or exclude) any events.
For example, you want to exclude event ID 123 from triggering an alert on all windows devices. To do this, set the property FILTEREDEVENTS to 123 on the top level of the device tree. This setting will be inherited by all lower nodes.
For one group of servers, you want to exclude event ID's 123, as well as 456 and 789 from triggering alerts. In this case, you can set the FILTEREDEVENTS property to the expression 123|456|789 on the group level. This will override the inherited property that has been set on the root level device group just for that device group and lower nodes.
For a specific server within this group, you might be interested in alerting on all events including 123, but not 456 or 789. You can set the FILTEREDEVENTS property again on this specific server to 234|456 to override the inherited property from all levels above.
If you want to filter on a composition of both the filtered events set on the upper group + the lower group, define an additional ##FILTEREDEVENTS1##, ##FILTEREDEVENTS2##, etc. token variable in the EventSource definition, and then define these separately at different levels of your device group tree structure. Make one token for each device group level in your device group tree structure that you would like to cumulatively match.
The standard filters described above are all combined with an AND clause - i.e. an event must meet the criteria specified in each and every filter in order to be alerted on. This is sufficient for most cases - but not for cases where more specificity is required (e.g. ignore eventID 123 if it is from IIS, but alert on it otherwise), or where several conditions are sufficient to trigger the alert (e.g. alert if Level is error or higher, or if the alert is eventID 123)
Complex Event Filtering
If Complex filtering is checked, a Groovy script can be used to filter events. The script should return a boolean value as the filter's result. Otherwise, the value of last expression will be the return value.
The event will only be detected and trigger alerts if the return value is true. If the return value is false or null, the event will not be detected. All other values will throw an exception and cause filtering to fail.
Complex Windows Event Filters do not have validity checking. Thus, simple filtering should be used where possible.
For instance, if you were filtering based on a wide range of Event IDs, ie. between 4000 and 5000, you would use the following Groovy script:
(EVENTID>'4000') && (EVENTID < '5000')
The following predefined variables can be used to access data about the event being processed:
For a more complete definition of each variable, see https://msdn.microsoft.com/en-us/library/aa394226(v=vs.85).aspx. Note the names of properties are translated to uppercase.
There are many operators in Groovy, but it is worth calling out the regular expression operator: