A rule is a workflow that adheres to certain rules. A rule is not used to monitor or alter state in any way. A rule is used for stateless monitoring only. Common types of rules include rules to collect data in the database and / or data warehouse and rules to generate alert where there is no notion of state.
A rule must consist of the following modules:
Probe action modules are not allowed in a rule definition. However a probe may be part of another composition e.g. a script based data source will likely combine a scheduler and a probe action into a composite data source.
A rule has the following attributes:
|
Name
|
Type
|
Use
|
Description
|
|
ID
|
ManagementPack
UniqueIdentifier
|
Required
|
The identity of the element. This must be unique within all elements of the management pack
|
|
Comment
|
ManagementPackString
|
Optional
|
Use for author comments.
|
|
Enabled
|
ManagementPack
MonitoringLevel
|
Optional
|
Defines if the rule is enabled by default. Set to true or false. Other values allowed are OnEssentials, OnStandard, OnAdvanced. These will only be enabled in conjunction with category overrides.
|
|
Target
|
ManagementPack
IdentifierReference
|
Required
|
The target class. The workflow will run against all instances of the targeted class
|
|
Confirm
Delivery
|
xsi:boolean
|
Optional
|
TBC
|
|
Remoteable
|
xsi:boolean
|
Optional
|
Defines whether this workflow will run for agentless monitoring. If it is not specified it is assumed to be true
|
|
Priority
|
ManagementPack
WorkflowPriority
|
Optional
|
TBC
|
|
DiscardLevel
|
xsi:int
|
Optional
|
TBC
|
Category
The category of a rule must be one of the following strings:
-
PerformanceCollection
-
Operations
-
EventCollection
-
StateCollection
-
SoftwareAndUpdates
-
Alert
-
Custom
-
AvailabilityHealth
-
PerformanceHealth
-
ConfiguraitonHealth
-
SecurityHealth
-
Notification
-
Maintenance
Although the following are allowed categories you should not used them as they are used for other purposes:
-
Discovery
-
DSIntegration
-
ConnectorFramewory
-
ExceptionMonitoring
The category field is not really used for anything in Operations Manager 2007. Category overrides can take advantage of this field but this concept is not exposed in the Ops Mgr UI.
Data Sources
The data sources element contains one or more data source modules of a specific module type. Unless you are performing some sort of correlation between data items, you will normally use a single data source. If you use more than one, you must include a condition detection module in your rule that accepts the correct number of inputs.
Illustration from Altova XML Spy
A data source must reference a data source module type previously declared in this management pack or a referenced management pack. This element is considered a Management Pack Sub-Element and can have a display string defined for it. The data source element has the following attributes
|
Name
|
Type
|
Use
|
Description
|
|
ID
|
ManagementPackLocal
IdentifierReference
|
Required
|
The identity of the sub-element. This must be unique within the containing element i.e. the rule.
|
|
Comment
|
ManagementPackString
|
Optional
|
Use for author comments.
|
|
RunAs
|
ManagementPack
IdentifierReference
|
Optional
|
References a secure reference. You should use this attribute only if you want to associate this module with a Run As profile.
|
|
TypeID
|
ManagementPack
IdentifierReference
|
Optional
|
The ID of the data source module type that is to be used.
|
The data source element must contain the necessary configuration for the module type. MPVerify will check this configuration. It is not possible for XML tools to verify the inner XML of the data source element because this is a schema within a schema. The MP Schema allows any XML.
Condition Detection
The rule can have zero or one condition detection modules. If you have more than one data source you must use a condition detection module and it must accept the correct number of input data streams. The condition detection module must contain the necessary configuration for the module type.
The attributes for the condition detection module are the same as for a data source module:
|
Name
|
Type
|
Use
|
Description
|
|
ID
|
ManagementPackLocal
IdentifierReference
|
Required
|
The identity of the sub-element. This must be unique within the containing element i.e. the rule.
|
|
Comment
|
ManagementPackString
|
Optional
|
Use for author comments.
|
|
RunAs
|
ManagementPack
IdentifierReference
|
Optional
|
References a secure reference. You should use this attribute only if you want to associate this module with a Run As profile.
|
|
TypeID
|
ManagementPack
IdentifierReference
|
Optional
|
The ID of the condition detection module type that is to be used.
|
You should note that often an expression filter is built into a composite data source e.g. when monitoring from a Windows event log, the data source takes the log name, the computer and the filter expression. There is no need to use an additional filter in most cases.
Write Actions
A rule must define at least one write action. Normally the write action will write data into the Operations Manager database and / or data warehouse. This does not have to be the case though. For example the write action could be to run a script, or generate an alert. Note that if you want to write data into either of the Ops Mgr database it must be Event, Performance or Alert data. You can map any data type to an Event or Perf data type using a mapping module. Also any data type can be used to generate an alert.
Illustration from Altova XML Spy
The write action module must contain the necessary configuration for the module type.
The attributes on a write action are:
|
Name
|
Type
|
Use
|
Description
|
|
ID
|
ManagementPackLocal
IdentifierReference
|
Required
|
The identity of the sub-element. This must be unique within the containing element i.e. the rule.
|
|
Comment
|
ManagementPackString
|
Optional
|
Use for author comments.
|
|
RunAs
|
ManagementPack
IdentifierReference
|
Optional
|
References a secure reference. You should use this attribute only if you want to associate this module with a Run As profile.
|
|
TypeID
|
ManagementPack
IdentifierReference
|
Optional
|
The ID of the write action module type that is to be used.
|
|
Target
|
ManagementPack
IdentifierReference
|
Optional
|
You can optional specify a different class to run the write action against. The main options for this are:
Microsoft.SystemCenter.ManagementServer
Microsoft.SystemCenter.RootManagementServer
This will have the effect of running a server side response.
|
Matching Data Types
When you are defining a workflow the output type of one module must be compatible with the input type of the next module in the workflow. For example if a data source outputs event data, you cannot use a write action that expects performance data. There are mapping modules that you can use if you ever need to change the data type. Data types following a hierarchy with all data types eventually inheriting from the System.BaseData data type defined in the System.Library MP. Therefore any module that accepts a data type of System.BaseData can take any data type. See the data types section of this site for more details.
Common Workflows
There are an almost unlimited number of workflows possible in a rule. The Operations Console exposes some of the most common ones through the rules wizard in the authoring space. You should familiarize yourself with the output of this wizard to see examples of common workflows. You should also refer to the type library section of this site for details of common module types that you may want to use in your workflows.