Use this Knowledge Script to scan the Windows logs you specify for entries that match the criteria you specify. You can filter the event log entries by event type and by specifying a combination of include and exclude strings for each event field using regular expressions. This script raises an event if a log entry matches all the filter criteria you specify. All event log entries that match the filtering criteria are returned in the event detail message.
Use the Filter the [...] field with the regular expression parameters to control which fields to filter and the filtering criteria to use to find specific information, such as events associated with a specific user or computer name. With this script, you specify the filtering criteria for each field you are interested in using a regular expression or you can specify the name of a file that contains all your filtering criteria.
For more information, see Creating Filters with Regular Expressions for General_EventLogRx.
You can use the Events in past N hours parameter to determine the number of previously recorded event entries, if any, to scan for matches. For example, if you want to check whether any event entries recorded in the last two hours, on the first job iteration, match your filtering criteria, you would set this parameter to 2. To scan the entire log for any previously reported events, set the Events in past N hours parameter to -1. After the Knowledge Script job completes its first iteration, only new entries written to the event log that match your criteria are reported. When the Events in past N hours parameter is set to 0, the script does not scan the log for any previously reported events.
This script requires the Async managed object to be installed and the Microsoft EventLog service to be running on the computer you want to monitor.
Windows computer or application server, such as Exchange Server or SQL Server
The default interval for this script is Every 10 minutes.
Set the following parameters as needed:
|
Parameter |
How to Set It |
|---|---|
|
General Settings |
|
|
Job Failure Notification |
|
|
Event severity when job fails |
Set the event severity level, from 1 to 40, to indicate the importance of an event in which the EventLogRX job fails. The default is 5. |
|
Event Log Monitoring |
|
|
Event log files to monitor |
Specify the event log you want to monitor. You can specify multiple event logs, separated by commas. For example: System,Application,Security. The default is Application. If you do not specify an event log, AppManager monitors all logs. Notes
|
|
Number of previous hours to scan logs |
Set this parameter to control how the script scans the logs at the first interval, after which scanning begins where the previous scan ended. Enter one of the following values:
The default is 0. |
|
Enforce case-sensitive filters? |
Select Yes to make all filter statements for this script case-sensitive. The default is unselected. |
|
Maximum number of entries per event report |
Specify the maximum number of entries to be recorded in each event's detail message. If this script finds more entries from the log than can be put into one event message, it will return multiple events to report all the outstanding entries in the log. The default is 30 entries. If this script encounters one or more very large events in the Windows Event log, this script may error out and generate an event message "Out of string space." If this occurs, you can usually work around the problem by adjusting this parameter to a smaller value. |
|
Ignore event log matches occurring during the agent maintenance mode? |
Select Yes for the Knowledge Script to ignore event log matches that occur while the agent is in maintenance mode. No events will be raised or data collected for matches that are written to the event logs during this time. The default is unselected. |
|
Full path to a file containing filtering criteria |
Type the full path to a file containing the filtering criteria you want to match if you want to specify matching expressions in an external file. For example: C:\TEMP\MyFilters.txt. NOTE:If you specify a filter file, AppManager ignores the Filter the [...] field with the regular expression parameters, but continues to scan the log file specified in the Log files to filter (Application, Security, System) parameter. However, if AppManager cannot process the filter file, the script raises an event (for example, fail to process filter file C:\general.xml) and continues to scan the log file using the filtering criteria you specified in the Filter the [...] field with the regular expression parameters. |
|
Event Log Filters |
|
|
Filter the [...] field with a regular expression |
Use a regular expression to specify the criteria to look for in each event log field you want to monitor:
NOTE:If you specify a filter file in the Full path to a file containing filtering criteria parameter, AppManager ignores the Filter the [...] field with the regular expression parameters, but continues to scan the log file specified in the Log files to filter (Application, Security, System) parameter. |
|
Event Notification |
|
|
Use XML format for event message |
Select Yes for event detail created by this Knowledge Script to be composed of XML. The default is unselected. NOTE:This parameter is only applicable when the agent computer is running version 8.0 or later of AppManager for Microsoft Windows. |
|
Raise event if log entries matching criteria are found? |
Select Yes raise an event when log entries match your filtering criteria. The default is Yes. |
|
Event severity when log entries match criteria |
Set the event severity level, from 1 to 40, to indicate the importance of an event in which log entries match your search criteria. The default is 15 (red event indicator). Tip You can adjust the severity based on which log or type of event you are checking for. |
|
Raise event if log cannot be accessed? |
Select Yes to raise an event when the log file cannot be read or reached. The default is Yes. |
|
Event severity when a log is inaccessible |
Set the event severity level, from 1 to 40, to indicate the importance of an event in which the log file cannot be read or reached.The default is 10. |
|
Data Collection |
|
|
Collect data for log entries that match criteria? |
Select Yes to collect data for charts and reports. When enabled, data collection returns detail about log entries that match your filtering criteria. The default is unselected. |
|
Separate data by log file? |
Select Yes to separate event entries from different log files into different datastreams. If unselected, all event entries matching your filtering criteria are placed in the same datastream and the data detail message can include event entries from multiple log sources. The default is unselected. For example, if you are monitoring both the System and Application logs, you can enable this parameter to track events in the System log separately from events in the Application log. |
Using this script you can specify regular expressions for each event log field as Knowledge Script properties or maintain your search criteria independent of the 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.
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 Full path to a file containing filtering criteria parameter and start the job.
There are two valid formats 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 file format appropriate for the complexity of the filtering you need to do.
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 and an AppManager event is raised. If you have more than one filtering section, an entry matching either section raises an event.
For example, the following table format 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 create only one filter section, you do not need to include the EventStart and EventEnd lines in the file. These lines are only required if you have more than one filtering section.
The XML format is somewhat 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></Include>
</EventLogConfig><Exclude>
<Events>
<Log>Application</Log>
<Type>Warning</Type>
<Source>RSVP</Source>
<Category>*</Category>
<EventID>2468</EventID>
<User>*</User>
<Computer>SHASTA</Computer>
<Description>RSVP*</Description>
<CaseSensitive>y</CaseSensitive>
</Events>
</Exclude>
</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.