Events

Applies To: System Center Operations Manager 2007

The following table lists the kinds of events that can be used for monitors and rules in a System Center Operations Manager 2007 management pack:

Text Log

Text log file that has a single line per entry.

Text Log (Delimited)

Text log file that has a single line per entry and fields separated by a specific character.

Windows Events

Events in the Windows event log matching specified criteria.

WMI Events

Events created by Windows Management Instrumentation (WMI).

Syslog Events

Events from Unix systems and other devices.

Details on each event data source are provided in the following sections. This includes the information that is required to retrieve the required data, properties available in the resulting data, and what workflows the event data source supports.

Windows Events

Many Windows-based applications post information to events in a Windows event log. These events follow a standard format and frequently contain detailed information about the particular issue

Criteria

In addition to the Application log to retrieve events from, workflows using a Windows event must specify sufficient criteria to identify the particular events that relate to the issue being identified. Frequently, the Event ID and the Event Source will be sufficient for this purpose. This depends on the kind of information that the application provides in the particular event in addition to the target that is being used for the monitor. If the class being used as the target for the monitor is expected to have multiple instances on a particular agent, then these two properties are probably insufficient for uniqueness. Unless the criteria included a key property for the target class then the criteria would possibly apply to all instances.

For example, the SQL Server 2008 (Monitoring) management pack uses an event to detect an error in a zone transfer. This event will have a publisher name of Microsoft-Windows-DNS-Server-Service and an event number of 6002. This monitor is called Microsoft.Windows.DNSServer.2008.Monitor.ZoneTransfer.ReinitializeZoneTransfer and uses the Microsoft.Windows.DNSServer.2008.Zone class for a target. This class is expected to have multiple instances on a particular agent. If multiple zones were hosted on a single DNS server, and only the publisher name and event number were used then the single event would be recognized by each instance. Each instance would set a negative health state even though the event was intended for only one zone. In this case, the name of the zone experiencing the issue is provided in parameter 2 of the event. Criteria is added to the monitor to match the name of the zone with the value in this event parameter to ensure that the criteria for each event matches only one instance of the Microsoft.Windows.DNSServer.2008.Zone class.

Properties

The following table lists the properties available from Windows Events. These properties can be accessed for setting criteria in monitors and rules and can be included in alert descriptions.

Property Name Description

PublisherName

Source of the event. Generally used in the criteria of the monitor or rule.

Channel

Name of the event log such as Application or System.

LoggingComputer

Name of the computer logging the event.

EventNumber

Number of the event.

EventCategory

Category of the event.

EventLevel

Severity of the event that uses one of the following values.

  • 0 - Success

  • 1 - Error

  • 2 - Warning

  • 4 - Information

UserName

Name of the user account that was used to create the event.

EventDescription

Full event description.

Params

Collection of event parameters.

Workflows Supported

Windows Events can be used in the following kinds of workflows:

  • Monitors

  • Alerting Rules

  • Collection Rules

Text Logs

A text log is a text file that an application uses to log event information. In order to use a text log data source in a management pack, each entry in the log must be on a single line. If the log file does not fit this requirement, then a custom script has to be created to read the log. Using a standard text log, the monitor reads the whole line as a single entry. With a delimited text log, a delimiter is used to separate the fields in the entry.

Applications that use log files frequently create a new file each day or when one file reaches a certain size. To support this functionality, monitors and rules specify a Directory and a Pattern for the text logs being monitored. Directory is the path of the directory where the text logs will be located. This must be an absolute path without wildcard characters. A $Target variable could also be used if the path to the log files is stored in a property of the target class. Pattern is the name of the log file including wildcard characters as appropriate.

For example, an application might create a log file each day with the date included in the name as in log20100316.txt. A pattern for such a log might be log*.txt which would apply to any log file following the application’s naming scheme.

Properties

The expression for a text log monitor will include criteria that matches text in the log entry. For a standard text log this includes a search of the whole log entry treated as a single line. For a delimited text file, this will include a search of one or more of the included fields. The contents of a text log are included in the parameters of the event. For a standard text file, this is referenced by the parameter $Data/Params/Param[1]$. A delimited text file uses the same $Data variable by using the index number of the required parameter. The first field would be referenced with $Data/Params/Param[1]$, the second field would be referenced with $Data/Params/Param[2]$, and so on.

The following table lists the common properties available from text log monitors and rules:

Property Name Description

LogFileDirectory

Directory that the log file is located in.

LogFileType

CSV Log File Format for a delimited text log.

Generic Log File Format for text log.

LogFileName

Name of the log file that the event was taken from.

Param[1]

Complete entry in a standard text file.

Param[#]

Specific parameter in a delimited text file. # represents the number of the field.

Workflows Supported

Text Logs can be used in the following kinds of workflows:

  • Monitors

  • Alerting Rules

  • Collection Rules

WMI Events

WMI events are created from WMI queries that detect particular actions in the operating system or in applications that create their own WMI events. These events can be used to detect such actions as a process ending, a file being created, or a registry key being modified. WMI events are not persisted. Therefore, any WMI events that are created when the agent service is not running are lost.

Note

This guide assumes knowledge of how to build a WMI notification query. For a an overview of this topic and sample queries see Unlocking the Mystery of WMI Events in MOM.

WMI monitors and rules require a namespace, a query, and a poll interval. The poll interval specified in the monitor or rule should match the poll interval in the query.

WMI matching poll intervals

WMI data source poll interval

Criteria

Because criteria can be specified in the WHERE clause of the WMI query, criteria is frequently not required in the monitor or rule. It is only required if the query is expected to return multiple records.

Note

The Authoring Console wizards require that criteria be specified in WMI Event monitors and rules. If no criteria is required, then dummy criteria should be specified in the wizard and then removed by viewing the properties of the monitor or rule.

Properties

Collection[@Name='TargetInstance']/Property[@Name='Caption']

Workflows Supported

WMI events can be used in the following kinds of workflows:

  • Monitors

  • Alerting Rules

  • Collection Rules

Syslog Events

Syslog events can be used to collect messages from Unix systems and other devices. Syslog rules can be run on an agent that is the receiver of messages from one or more devices. When the rule is run, the agent will listen for messages on UDP port 514. This is the only port that can be used.

Properties

The Syslog data properties are shown in the following table:

Property Name Description

Facility

The facility of the event that uses one of the values from the table that follows.

Severity

Numeric value that indicates the severity of the event using one of the following values:

  • 0 - Emergency

  • 1 - Alert

  • 2 - Critical

  • 3 - Error

  • 4 - Warning

  • 5 - Notice

  • 6 - Info

  • 7 - Debug

Priority

PriorityName

TimeStamp

Time that the message was sent.

HostName

Name of the device sending the message

Message

Text of the message

Facility Values

The value for the facility property defines the part of the system that the message originated from. It will have one of the values from the following table:

Facility Description Value

0

Kernel

Kernel messages

1

User

User-level messages

2

Mail

Mail System

3

Daemons

System daemons

4

Auth

Security and authorization

5

Syslog

Syslog internal messages

6

LPR

Line printer subsystem

7

News

Network news

8

UUCP

Unix-to-Unix copy program

9

Cron

Cron daemon

10

Auth2

Security and authorization

11

FTP

FTP daemon

12

NTP

Network time subsystem

13

LogAudit

14

LogAlert

15

Cron2

Cron daemon

16

Local0

Local use 0

17

Local1

Local use 1

18

Local2

Local use 2

19

Local3

Local use 3

20

Local4

Local use 4

21

Local5

Local use 5

22

Local6

Local use 6

23

Local7

Local use 7

Workflows Supported

Syslog events can be used in the following kinds of workflows:

  • Alert Rules

  • Collection Rules