Rule
Applies To: System Center 2012 - Operations Manager, System Center 2012 R2 Operations Manager, System Center 2012 SP1 - Operations Manager
Defines a workflow that is used for stateless monitoring.
Schema Hierarchy
ManagementPack
Monitoring
Rules
Rule
Syntax
<Rule ID=”RuleID” Comment=”Comment” Enabled=”True/False” Target=”TargetClassID” ConfirmDelivery=”True/False” Remotable=”True/False” DiscardLevel=”SomeNumber”> <Category>CategoryName</Category>
<DataSources>…</DataSources>
<ConditionDetection>…</ConditionDetection>
<WriteActions>…</WriteActions>
</Rule>
Attributes and Elements
The following sections describe attributes, child elements, and the parent element of the Rule element.
Attributes
Attribute | Description |
---|---|
ID |
Required attribute. Represents the identity of the element. To learn how to identify your element in a management pack, see Element Identity and Namespace Conventions. |
Comment |
Optional attribute. Represents commentary by the management pack author. |
Enabled |
Required attribute. Defines whether or not this workflow is by default enabled or disabled. |
Target |
Required attribute. The ID of the targeted class type. |
ConfirmDelivery |
Optional attribute. Defines whether or not the module following the data source module will notify the data source that it has received the data. The default value is false. |
Remotable |
Optional attribute. Defines whether or not this workflow will run for agentless monitoring. Default value is true. |
DiscardLevel |
Optional attribute. Internal usage only. |
Enabled Attribute Values
Value | Description |
---|---|
True |
The workflow is enabled and will run when its target class has been discovered. |
False |
The workflow is disabled and will not run even when its target class has been discovered. |
Target Attribute Values
Value | Description |
---|---|
The ID of the targeted ClassType element. |
A rule is always targeted at a particular class type and runs against every instance of that class type. |
Child Elements
Element | Description |
---|---|
Represents the category name of the rule. For the list of allowable names, see Category (Rule). |
|
Required element. Contains one or more data source modules. |
|
Optional element. Represents an implementation of a condition detection module type definition. |
|
Required element. Contains one or more write action modules. |
Parent Elements
Element | Description |
---|---|
Contains rule definitions targeted at a specific entity type in the service model. |
Remarks
Rules are workflows that must conform to the following requirements:
Must contain at least one DataSource (Rule) module.
May contain zero or one ConditionDetection (Rule) modules.
Must contain at least one WriteAction (Rule) module.
Notice that a rule cannot contain a ProbeAction (DataSourceModuleType) module directly. However, it can contain a data source module that has a ProbeAction module in its MemberModules (DataSourceModuleType) element.
Rules usually, but not necessarily, write to the Operations Manager database or the Data Warehouse. In that case, a condition detection module may be included in the workflow if the OutputType (DataSourceModuleType) element of the data source module is neither a System.Event.Data type nor a System.Performance.BaseData type.
Usually, it is a best practice to use monitors to monitor state and optionally create alerts from state changes. However, if you would like to generate an alert out of an event that does not reference any state change, you can create a rule that detects the event and generates a health alert with the System.Health.GenerateAlert write action module defined in the System.Health.Library management pack. When using this module, it is not necessary to provide two write action modules for each database. The module automatically writes the alert to both databases.
There are cases where multiple identical alerts can be created. This is usually undesirable, because only one alert is required. For more information about alert suppression, see System.Health.GenerateAlert.
The ConfirmDelivery attribute should be set to true only when you find that the workflow is failing to pass data from the data source to the next module in the workflow. This would happen when the amount of data surpasses a predefined system threshold. When it surpasses this threshold, data items will be dropped for performance reasons. However, when ConfirmDelivery is set to true, the data will not be dropped but the next module in the workflow will acknowledge delivery of the data item to the data source module before it receives its next piece of data.
Below are some samples of common rule types.
Example
The first XML sample demonstrates a rule that collects event data and writes it to the Operations Manager database and the Data Warehouse whenever the Windows Event log receives a "Duplicate Name Exists" event. The data source module uses the $Target/Host notation to retrieve contextual data from the rule’s target, Microsoft.Windows.Client.XP.OperatingSystem
. For more information, see $Target.
<Rule ID="Microsoft.Windows.Client.XP.OperatingSystem.DuplicateNameonNetwork.Alert" Enabled="onEssentialMonitoring" Target="Microsoft.Windows.Client.XP.OperatingSystem">
<Category>EventCollection</Category>
<DataSources>
<DataSource ID="EventDS" TypeID="Windows!Microsoft.Windows.EventProvider">
<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<LogName>System</LogName>
<Expression>
<And>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>PublisherName</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>TCPIP</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
<Expression>
<Or>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>EventDisplayNumber</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>4319</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>EventDisplayNumber</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>4320</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
</Or>
</Expression>
</And>
</Expression>
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
<WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData" />
</WriteActions>
</Rule>
The following XML sample demonstrates a rule that gathers the percentage of free space on a logical drive every five minutes if the delta of change is 1 or if collection has not occurred within the hour. For more information about the data source module in this sample, see System.Performance.OptimizedDataProvider.
After collection by the data source, the rule then writes the System.Performance.BaseData to the Operations Manager database and the Data Warehouse. The data source module uses $Target/Host notation to retrieve contextual data from the rule’s target, Microsoft.Windows.Server.2003.LogicalDisk
. For more information, see $Target.
<Rule ID="Microsoft.Windows.Server.2003.LogicalDisk.FreeSpace.Collection" Enabled="onEssentialMonitoring" Target="Microsoft.Windows.Server.2003.LogicalDisk">
<Category>PerformanceCollection</Category>
<DataSources>
<DataSource ID="PerformanceDS" TypeID="SystemPerf!System.Performance.OptimizedDataProvider">
<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<CounterName><![CDATA[% Free Space]]></CounterName>
<ObjectName>LogicalDisk</ObjectName>
<InstanceName>$Target/Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$</InstanceName>
<AllInstances>false</AllInstances>
<Frequency>300</Frequency>
<Tolerance>1</Tolerance>
<ToleranceType>Absolute</ToleranceType>
<MaximumSampleSeparation>12</MaximumSampleSeparation>
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectPerformanceData" />
<WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData" />
</WriteActions>
</Rule>
The following XML sample demonstrates a rule that creates a health alert whenever the Windows Event log receives an IP address conflict event. This sample uses the following variable notations to retrieve contextual data: $Target, $Data, $MPElement. For more information, see Variable Notation.
<Rule ID="Microsoft.Windows.Server.2003.OperatingSystem.IPAddressConflict.Alert" Enabled="onEssentialMonitoring" Target="Microsoft.Windows.Server.2003.OperatingSystem" ConfirmDelivery="true">
<Category>EventCollection</Category>
<DataSources>
<DataSource ID="EventDS" TypeID="Windows!Microsoft.Windows.EventProvider">
<ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<LogName>System</LogName>
<Expression>
<And>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>PublisherName</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>TCPIP</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
<Expression>
<SimpleExpression>
<ValueExpression>
<XPathQuery>EventDisplayNumber</XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>4199</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
</And>
</Expression>
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID="GenerateAlert" TypeID="SystemHealth!System.Health.GenerateAlert">
<Priority>1</Priority>
<Severity>2</Severity>
<AlertMessageId>$MPElement[Name="Microsoft.Windows.Server.2003.OperatingSystem.IPAddressConflict.Alert.AlertMessage"]$</AlertMessageId>
<AlertParameters>
<AlertParameter1>$Data/EventDescription$</AlertParameter1>
</AlertParameters>
<Suppression>
<SuppressionValue />
</Suppression>
</WriteAction>
</WriteActions>
</Rule>