The initial install of EventSentry includes several default packages that match common scenarios our customers face. For example, when an error is detected on a hard disk most administrators would like to receive an alert. However, there may be some events that are a bit more specific to your network that you would like to receive. If you are monitoring for events that have a unique source or event id this process may not be that difficult. On the other hand, if you have ever monitored for an event that shares the same information with another event (i.e. source, category, or id) or it is an event found in the Security log, you will realize the importance of being able to filter by the unique text in the event message itself.
As an example let's take a look at EventSentry's Service Monitoring, which writes all status changes, regardless of the service or the type of status change, as ID 10100.
Negative status change of Print Spooler - Running to Stopped
Negative status change of Print Spooler - Stopped to Running
In this scenario filtering by the text in the event message is crucial for us to filter out the events we would like to receive. Let's say you only want to receive an email when the Print Spooler status changes.
Once you have a basic filter set up for event 10100, we can add content filters to specify that the filter only match for events about the print spooler service. (See our how-to guides for more on creating basic event log filters here and how to create event log filters from the event log viewer here!) In our example below, we will receive an email EVERY time ANY service changes status! We only want to receive emails about the print spooler, so we need to add a content filter.
If we click the + button next to the content filters pane and add a wildcard match, we can add the text:
*spooler*
And now our filter will ONLY match 10100 events that include the text "spooler" in the event text.
The * wildcard around our content filter tells EventSentry to match any text that comes before or after "spooler." This allows the filter to match any event that contains the word "spooler" anywhere in the event text. We will go more over wildcards at the end of this article.
We can get even more specific with our content filters. Say we only want to receive an email when the print spooler stops. We'll need to add a second content filter. If we add a second content filter that matches:
*Running to Stopped*
Then our filter will only alert us when the print spooler service stops. Notice we chained the two content filters with AND. This means both content filters must be present in the event text for the event log filter to match. This as opposed to the "OR" chain, which would match if just one content filter is present.
As you can see, using content filters can drastically improve the quality of your content filters and allow you more control over what alerts you receive.
Wildcards
Wildcard characters will match ANY character or characters, allowing you to configure filters that match multiple events without the need to match event text exactly.
The wildcards * and ? are supported.
A * matches zero or more occurrences of any character
A ? matches one occurrence of any character.
Wildcards can be used in any of the follow fields in an event log filter (Regular expression support is also available when matching event log content):
Event Source
Category
Username
Filter Text
Computer
Examples
1)
Wildcard:
ipx*
Will match:
IPXCP
IPXRouterManager
2)
Wildcard:
*iptables*proto=??p*dpt=13*
Will match:
syslog@netikus-router[kern.debug]: kernel: IPTABLES INPUT: IN=ppp0 OUT= MAC= SRC=65.35.223.155 DST=65.41.63.146 LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=54221 DF PROTO=TCP SPT=1429 DPT=135 WINDOW=64240 RES=0x00 SYN URGP=0
3)
Wildcard:
VMnet*
Will Match:
VMnetAdapter
VMnetDHCP
VMnetuserif
4)
Wildcard:
*rip*
Will match:
IPRIP2
IPXRIP