This document is part of the Operations Manager Management Pack Authoring Guide .
The following procedure shows how to create a monitor and rule based on a common data source module using the Operations Manager 2007 Authoring console and Visual Studio Authoring Extensions.
This exercise applies to the following products:
Before you perform this procedure, you must first complete the following prerequisite procedures:
The Microsoft System Center team has validated this procedure as of the original revision. We will continue to review any changes and periodically provide validations on later revisions as they are made. Please feel free to make any corrections or additions to this procedure that you think would assist other users
A sample of the completed code for each exercise is available in the TechNet Gallery. There is a separate sample for each exercise that includes the management pack completed at the end of that exercise and each preceding exercise. This strategy allows you to work through each exercise in order and then compare your results. For VSAE, this also includes the Visual Studio solution.
The workflows created in this procedure have the following characteristics:
<![CDATA[
sComputerName = WScript.Arguments(0)
sVersion = WScript.Arguments(1)
Set
oAPI = CreateObject(
"MOM.ScriptAPI"
)
oAPI.LogScriptEvent
"MyCookdownScript.vbs"
,10,4,
"Running script on "
& sComputerName &
". Version is "
& sVersion
For
i = 1 to 3
oBag = oAPI.CreatePropertyBag()
Call
oBag.AddValue(
"ComputerName"
,sComputerName)
"ComponentName"
,
"Component"
& i)
"Value"
,30)
oAPI.AddItem(oBag)
Next
oAPI.ReturnItems
]]>
<IntervalSeconds>$Config/IntervalSeconds$</IntervalSeconds>
<
IntervalSeconds
>$Config/IntervalSeconds$</
>
add the following line:
<SyncTime>$Config/SyncTime$</SyncTime>
SyncTime
>$Config/SyncTime$</
The first data source module will run the script and map its output to performance data. The script is intended to return data for each instance of the target class. In the case of this example, the script just returns three property bags to illustrate the concept.
Since the values for the parameters provided to the module will be the same for all instances, the module is able to cookdown. It runs only one instance of the script but returns multiple performance data items. Each data item includes the name of the component so that we know which component each data item belongs to.
sComputerName = WScript.Arguments(0) sVersion = WScript.Arguments(1) Set oAPI = CreateObject("MOM.ScriptAPI") oAPI.LogScriptEvent "MyCookdownScript.vbs",10,4, "Running script on " & sComputerName & ". Version is " & sVersion For i = 1 to 3 Set oBag = oAPI.CreatePropertyBag() Call oBag.AddValue("ComputerName",sComputerName) Call oBag.AddValue("ComponentName","Component" & i) Call oBag.AddValue("Value",30) oAPI.AddItem(oBag) Next oAPI.ReturnItems
DataSourceModuleType
ID
=
"MyMP.DataSourceModule.MyPerformanceScriptTimed"
Accessibility
"Internal"
Batching
"false"
Configuration
xsd:element
minOccurs
"1"
name
"IntervalSeconds"
type
"xsd:integer"
/>
"0"
"SyncTime"
"xsd:string"
"Version"
</
OverrideableParameters
OverrideableParameter
Selector
"$Config/IntervalSeconds$"
ParameterType
"int"
"$Config/SyncTime$"
"string"
ModuleImplementation
Isolation
"Any"
Composite
MemberModules
DataSource
"Script"
TypeID
"Windows!Microsoft.Windows.TimedScript.PropertyBagProvider"
ScriptName
>MyCookdownScript.vbs</
Arguments
>$Config/ComputerName$ $Config/Version$</
ScriptBody
>$IncludeFileContent/Composition/MyCookdownScript.vbs$</
TimeoutSeconds
>300</
ConditionDetection
"MapToPerf"
"Perf!System.Performance.DataGenericMapper"
ObjectName
>MyApp</
CounterName
>TestCounter</
InstanceName
>$Data/Property[@Name='ComponentName']$</
Value
>$Data/Property[@Name='Value']$</
Composition
Node
OutputType
>Perf!System.Performance.Data</
The second data source module gets the performance data from the first data source module and filters it for a single instance. This module will output a single performance data item for a particular component.
This module will not cookdown because a different value is provided to the ComponentName parameter for each instance of the target class. This is a lightweight module though, so the effect of this is minimal. The significant overhead comes from the script run from the first data source module, and that script will cookdown.
"MyMP.DataSourceModule.MyPerformanceScriptFiltered"
ComputerName
>$Config/ComputerName$</
Version
>$Config/Version$</
"FilterComponent"
"System!System.ExpressionFilter"
Expression
SimpleExpression
ValueExpression
XPathQuery
Type
"String"
>InstanceName</
Operator
>Equal</
>$Config/ComponentName$</
The rule calls the second data source module providing the name of the application component.
>900</
>$Target/Host/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</
>$Target/Host/Property[Type="MyMP.MyComputerRoleBase"]/Version$</
ComponentName
>$Target/Property[Type="MyMP.MyApplicationComponent"]/ComponentName$</
The monitor type calls the data source module and defines the logic for determining different health states.
UnitMonitorType
"MyMP.MyApplicationComponentMonitorType"
MonitorTypeStates
MonitorTypeState
"UnderThreshold"
NoDetection
"OverWarningThreshold"
"OverErrorThreshold"
"WarningThreshold"
"ErrorThreshold"
"SyncTIme"
"$Config/WarningThreshold$"
"$Config/ErrorThreshold$"
MonitorImplementation
"DataSource"
"FilterUnderThreshold"
"Integer"
>Value</
>Less</
>$Config/WarningThreshold$</
"FilterOverWarningThreshold"
>GreaterEqual</
"FilterOverErrorThreshold"
>$Config/ErrorThreshold$</
RegularDetections
RegularDetection
MonitorTypeStateID
WarningThreshold
>10</
ErrorThreshold
>20</