Use this Knowledge Script to determine whether a Windows event log does not contain an expected entry. This script raises an event if the Application, Security, or System event log does not contain an entry that matches your filtering criteria. You can use regular expressions or text/numeric strings to specify filtering criteria.
For more information, see Section 8.1, Creating Filters with Regular Expressions for General_AsciiLogRX.
For example, the SQL backup process normally adds an entry to the event log to indicate databases were successfully backed up. This script can search for log entries that match your filtering criteria and raise an event if the event log does not contain an entry for a successful SQL backup.
To determine whether a Windows event log does contain an entry matching your filtering criteria, use the EventLog Knowledge Script.
NOTE:If you use text/numeric strings in the Event [...] filter parameters, this script searches event logs and matches the filter string to any part of the event entry. The results are not exact matches. For example, if your filter string is “foo,” results will include “foobar,” “foo,” and “food.”
Results for regular expression filters are exact matches.
Windows computer or application server, such as Exchange Server or SQL Server
By default, this script runs every hour.
Set the following parameters as needed:
Parameter |
How to Set It |
---|---|
General Settings |
|
Job Failure Notification |
|
Event severity when job fails |
Set the severity level, from 1 to 40, to indicate the importance of an event in which the MissingEvent job fails. The default is 25. |
Event Log Monitoring |
|
Event logs to monitor |
Indicate the name of the event log you want to monitor, separating multiple names with a comma. For example: System,Application,Security The default is Application. NOTE:If the event log you specify does not exist on the target computer, the Application log is automatically monitored. |
Number of hours to scan logs |
Set this parameter to control how the script scans the logs in the first interval, after which scanning begins where the previous scan ended. Enter one of the following values:
The default is 0. |
Event Log Filters |
|
Use regular expressions for filter criteria? |
Select Yes to use a regular expression to specify the criteria to look for in each event log you want to monitor. The default is unselected. You can use regular expressions in the Event [...] filter parameters, or you can create an external .txt file that contains the regular expressions you want to use as filtering criteria. |
Enforce case sensitivity in regular expressions? |
Select Yes to enforce case-sensitivity in all regular expressions used in the filter parameters or in the external .txt file. The default is unselected. |
Event type for regular expression filtering |
Use a regular expression to identify the type of event entries to search for in the logs: Error, Warning, Information, Audit_Success, Audit_Failure, Unclassified. |
Path to file containing regular expression filters |
Provide the full path to a file containing the regular expression filtering criteria you want to find in each monitored event log. For example: C:\TEMP\MyFilters.txt. Format the contents of the .txt file as described in Using an External Filter File. NOTE:If you specify a filter file, AppManager ignores the Event [...] filter parameters, even if the filter file is inaccessible for any reason, but continues to scan the log file specified in the Event logs to monitor parameter. |
Event Types |
|
Error |
Select Yes to search for log entries with an event type of Error. The default is Yes. |
Warning |
Select Yes to search for log entries with an event type of Warning. The default is Yes. |
Information |
Select Yes to search for log entries with an event type of Informational. The default is Yes. |
Success Audit |
Select Yes to search for log entries with an event type of Success Audit. A Success Audit event is an audited security access attempt that succeeds. The default is Yes. |
Failure Audit |
Select Yes to search for log entries with an event type of Failure Audit. A Failure Audit event is an audited security access attempt that fails.The default is Yes. |
Unclassified |
Some events written to Windows event logs do not have event levels or severities set to event types recognized by Windows Server 2008 and later. This Knowledge Script identifies these entries as unclassified. These entries will not be found by the error, warning, informational, success audit, or failure audit filter criteria. Set to Yes to monitor log entries that are unclassified. The default is Yes. |
Event source filter |
To search for log entries generated by a particular source (such as SQLExecutive, SNMP, or the Service Control Manager), enter a search string or a regular expression. This script will look for matching entries in the event log’s Source field. Separate multiple strings with commas. |
Event category filter |
To search for log entries in a particular category (such as Server or Logon), enter a search string or regular expression. This script will look for matching entries in the event log’s Category field. Separate multiple strings with commas. |
Event ID filter |
To search for log entries with particular event IDs, enter a search string, regular expression, or ID range (for example 100-2000). This script will look for matching entries in the event log’s Event field. Separate multiple IDs and ranges with commas. For example: 1,2,10-15,202. |
Event user filter |
To search for log entries associated with a particular user, enter a regular expression or search string, for example, <domainname>\<username>. This script will look for matching entries in the Event log’s User field. Separate multiple strings with commas. |
Event computer filter |
To search for log entries generated by a particular computer, enter a search string or regular expression. This script will look for matching entries in the event log’s Computer field. Separate multiple strings with commas. |
Event description filter |
To search for log entries with a particular detail description or containing keywords in the description, enter a search string or regular expression. This script will look for matching entries in the event log’s Description field. Separate multiple strings with commas. |
Event Notification |
|
Raise event if entries are missing from event logs? |
Select Yes to raise an event if the selected event logs do not contain entries matching your filtering criteria. The default is Yes. |
Event severity when entries are missing from event logs |
Set the severity level, from 1 to 40, to indicate the importance of an event in which the selected logs do not contain entries matching your filtering criteria. The default is 5. |
Data Collection |
|
Collect data for missing log entries? |
Select Yes to collect data for charts and reports. If enabled, data collection returns the number of log entries found that match the filtering criteria. If no entries match the criteria, data collection returns 0 (zero). The default is unselected. |
Separate data by log file type |
Select Yes to separate event entries from different log files into different datastreams. If disabled, all event entries matching your filtering criteria are placed in the same datastream and the data detail message may include event entries from multiple log sources. For example, if you are monitoring both the System and Application logs, you can enable this parameter so that events in the System log are tracked separately from events in the Application log. The default is Yes. |
With the MissingEvent script, you can specify regular expressions for each Event [...] filter parameter or maintain your search criteria independent of the Knowledge Script parameters in a separate filter file.
In many cases, specifying an external filter file provides greater flexibility and makes modifying your search criteria more straightforward because you can add almost any number of expressions and you do not need to modify the Knowledge Script properties to pick up your changes.
NOTE:If you specify a filter file, AppManager ignores the Event [...] filter parameters, even if the filter file is inaccessible for any reason.
If you want to use a filter file:
Identify the strings that you want to find a match for, that is, the entries you want to include in your results.
Create a text file with one regular expression string per line to locate matching strings. Each line in the file consists of a parameter keyword followed by a colon (:), a tab or blank space, and the regular expression. Or the filter file can be written using XML.
Make sure the file exists on the target computer.
Type the absolute path to the file on the local computer in the Path to file containing regular expression filters parameter and start the job.
Two formats are valid for the filter file: a simple table format to define the strings to include and an XML format that allows you to define more complex include and exclude filtering. For both formats, the parameter name keywords are required, but the field values can be left blank if no filtering is needed.
Select a format appropriate for the complexity of your filtering needs.
The table format provides a simple way to create the filter file. Each filtering section in the file begins with EventStart and ends with EventEnd. If an entry in the event log matches all the criteria you have specified within a filtering section, it is considered a match; no AppManager event is raised. If you have more than one filtering section, a log entry can match either section. Remember, for the MissingEvent Knowledge Scripts, events are raised only when no log entry matches your criteria.
For example, the following table format file provides two filter sections:
EventStart CaseSensitive:n Log:System Type:Error|Warning|Information Source:^SQL* Category:* EventID:1[0-9][0-9][0-9] User:Sam|Joe|Chris Computer:SFO* Description:($Error.*)|(.*error.*occurred.$) EventEnd EventStart CaseSensitive:n Log:Application Type:Error|Warning|Information Source:^SQL* Category:* EventID:1[0-9][0-9][0-9] User:Sam|Joe|Chris Computer:SFO* Description:($Error.*)|(.*error.*occurred.$) EventEnd
NOTE:If you are only specifying one filter section, do not include the EventStart and EventEnd lines in the file.
The XML format is more sophisticated and more flexible than the table format. The XML format allows you to set both include and exclude filters using the <Include> and <Exclude> tags and to combine these filter sets to define the search criteria. Each filtering section in the file begins with the <Events> tag. A log entry must match all the criteria you specified within a filtering section for it to be considered a match.
For example:
<?xml version = "1.0" standalone = "yes"?> <EventLogConfig Name = "Event Filter" Type = "EVENT_FILTER_CUSTOM" ID = "76"> <Include> <Events> <Log>Application</Log> <Type>INFORMATION|WARNING|ERROR</Type> <Source><Net*]></Source> <Category>*</Category> <EVENTID>2*</EVENTID> <User>*</User> <Computer>*</Computer> <Description><![CDATA[Event.]]></Description> <CaseSensitive>y</CaseSensitive> </Events> <Events> <Log>System</Log> <Type>Warning</Type> <Source>RSVP</Source> <Category>*</Category> <EVENTID>*</EVENTID> <User>*</User> <Computer>SHASTA</Computer> <Description>RSVP*</Description> <CaseSensitive>y</CaseSensitive> </Events> </Include> </EventLogConfig>
NOTE:If a field contains a regular expression that conflicts with XML syntax or includes special characters, you can use ![CDATA[regular_expression]] to enclose the expression and prevent parsing problems.