Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
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). For instructions on how to correctly set up both Microsoft Subscriptions and your EventSource to accomplish this, see the Filter Required When Using Subscriptions to Copy Events to Another Destination section of this support article.
You can define a new Windows Event Log EventSource from Settings | LogicModules | Eventsource | New | Eventsource.
To begin, set the Type field to “Windows Event Logging”.
Other fields that must be configured include:
Note: LogicMonitor’s pre-built Windows Event Log EventSources have filters that restrict alerting to error and critical level events.
Note: The ability to override duplicate EventID suppression requires Collector version 29.104 or higher.
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.
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.
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 IDs 123 as well as 456 and 789 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 group just for that 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 456|789 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)
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’)
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), as demonstrated in this video.
Once the logs are copied to a destination that is available to LogicMonitor, you will need to add a filter type of “LOGNAME” that equals <OriginalLogName>. As shown next, you can find your event’s original log name in the event details that display in the Event Viewer.
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:
In This Article