Filter timers give you the ability to ignore an event - even if it matches one of your filters - if a particular subsequent event occurs within a configurable amount of time.
Consider the following scenario: A critical service stops but is automatically restarted within 1 minute (e.g. after an AntiVirus engine has updated itself), resulting in two events generating an event in the event log. First, when the service stops and again when the service is restarted. You could of course stop the service from being monitored altogether, but that would not be desirable since you would want to be notified when the service stop without being restarted. Filter-Timers offer a solution to this problem.
Filter timers solve this problem by letting you create two filters: One filter to match the first event, and one to match the subsequent event which, in turn, clears the first alert. As such, you will never be notified of the original event if it has been cleared within the timeout period.
|
Keep in mind, that due to the nature of this feature you will not be notified of an event matching a filter with the Enable Timer option set, until the timer period has elapsed. |
Enabling a Timer
To enable a timer on filter, edit the filter and click on the Timers tab. On the Timers tab, select "Enable Timer" to activate the timer. Then, specify a timeout period (e.g. 2 minutes) and specify a filter that will clear the timer by clicking the plus + button. Clicking this button will bring up a dialog showing all suitable filters (e.g. include filters) that can be used to clear this timer.
The "Clearing" Filter
This filter is referenced by a timer filter, and has the ability to clear the timer. When setting up this filter, specify the same action as the action specified in the timer filter. If this filter matches while a timer filter is counting down from the set timeout, it will clear the timer, and the action will not be notified.
If the clearing filter matches an event while no timer is active, it will behave like a regular filter. As such, you can specify multiple actions on the clearing filter.
Insertion Strings
This feature is particularly useful when creating a filter timer that should match a variety of events. For example, a "service stop / service start" combination, a "process end / process start" combination or a "logon / logoff" combination. Without utilizing the insertion string feature, it would be necessary to create a filter pair for every unique event (e.g. service).
Let's say that you want to be notified if any monitored service were stopped for more than 5 minutes (or if a host is offline for more than 5 minutes etc). Let's assume that the DNS Server service were stopped, which would trigger a timer that would expire in 5 minutes. Let's also assume that the License Logging service were started on the same host 3 minutes after the DNS Server service was stopped. Because they both matched the generic filter that catches service start events, the timer would be cleared and you would not be notified of the stopped service.
Using insertion strings however, you can force EventSentry to compare the selected insertion strings from the originating event that set the filter timer, and the timer that is about to clear the filter. If they match, then the filter timer is cleared, otherwise it is not. We recommend that you use the Event Message Browser to determine the number and position of insertion strings inside events.
Consider the following EventSentry events that pertain to service monitoring as well as process creation / termination
Event Source |
Event Category |
Event ID |
Event Description (insertion strings start with % character) |
EventSentry |
Service Monitoring |
10100 |
The status for service %1 (%2) changed from %3 to %4. |
Microsoft-Windows-Security-Auditing |
Logon |
4624 |
An account was successfully logged on.
Subject: Security ID: %1 Account Name: %2 Account Domain: %3 Logon ID: %4
Logon Type: %9
Impersonation Level: %21
New Logon: Security ID: %5 Account Name: %6 Account Domain: %7 Logon ID: %8 Logon GUID: %13
|
Microsoft-Windows-Security-Auditing |
Logoff |
4647 |
User initiated logoff:
Subject: Security ID: %1 Account Name: %2 Account Domain: %3 Logon ID: %4 |
Whenever EventSentry records a service status change, it logs event 10100 to event log, and substitutes %1 with the name of the service whose status changed. As such, if require a match of insertion string #1, then an event pertaining to the "License Logging" service cannot clear the timer that was set from the "DNS Server service".
A similar setup could be achieved with the events logged by Windows when a user logs on and then logs off again. If we set a filter timer based on event 4624, and the filter clearing timer based on event 4647, then we need to connect insertion string #8 of the logon event with insertion string #4 of the logoff event.
When specifying insertion strings, both the insertion from the filter timer event AND the clearing event need to be specified. The same insertion string may be specified for both events if they are the same (in the examples above the insertion strings are the same for the service monitoring event but not for the logon/logoff events).
How it works
When an event matches a timer-enabled filter, EventSentry will wait until the timeout period has elapsed before it will forward the event to the configured notifications. EventSentry will append the string TIMER-DELAY to the subject of an email if one of the configured notifications is of type SMTP.
If the filter specified in the "Filter that can clear this timer" list matches an event within the timeout period, then the neither the original nor the "clearing" filter will process the notification, the objective of this feature.
Controlling Notifications
The point of a filter timer is of course to suppress notifications if the event starting a filter timer is cleared within the configured time period. Consequently, there is no scenario where EventSentry would send out a notification if the timer filter is cleared.
It is possible to control whether notifications are sent out if the event clearing a filter timer happens outside the configured time window. For example, a filter timer for a service is configured for 3 minutes, but the service is restarted after 4 minutes. Depending on the circumstances, it may or may not be desirable to receive a notification when the filter clearing the timer processes the event.
Receiving a notification
To trigger a notification when the event happens outside the configured time window, simply configure the same action on the clearing filter as on the timer filter. If the event that is supposed to clear the timer happens delayed, outside the timer window, then it will trigger a notification. In the case of the service monitoring example, this would inform the user that the service was ultimately restarted, albeit with a delay.
Suppressing notifications
To suppress notifications and strictly get notified that the filter timer expired, then no action should be specified on the timer clearing filter. This will still clear the timer filter if the event happens in the specified time window, but will not send any notifications if the event occurs outside (after) the time window.
