A unit monitor is used to monitor a particular aspect of an object such as an application, device or service. A unit monitor uses some instrumentation or some probing action to determine the current state of the aspect e.g. Windows Events, Perf data, log files, WMI, SNMP, Scripts.
A unit monitor is defined to be of a particular unit monitor type. You should refer to the type definitions section of this schema guide for more information on creating monitor types. Out of the box Operations Manager 2007 ships with over 200 monitor types. These are predefined workflows that monitor for specific types of instrumentation. Some of the Windows Event based monitor types as defined in the Microsoft.Windows.Library MPare:
You should refer to the type library section of this site for details of all the monitor types and what they do (coming soon!). If you cannot find the monitor type to suit your needs you can create a new monitor type.
A unit monitor will always roll health up to a parent aggregate monitor and the health will ultimately be rolled up to the health of an object in Operations Manager.
The schema for a unit monitor is:
Illustration from Altova XML Spy
The attributes for a Unit Monitor are:
|
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.
|
|
Accessibility
|
ManagementPack
Accessibility
|
Required
|
Defines visibility of element from other MPs. Set to internal or public
|
|
Enabled
|
ManagementPack
MonitoringLevel
|
Optional
|
Defines if the monitor 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. The default is true if this attribute is not set
|
|
Target
|
ManagementPack
IdentifierReference
|
Optional
|
The target class. The monitor will run against all instances of the targeted class.
|
|
Parent
MonitorID
|
ManagementPack
IdentifierReference
|
Required
|
The aggregate monitor to roll health up to.
|
|
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
|
|
RunAs
|
ManagementPack
IdentifierReference
|
Optional
|
References a secure reference. You should use this attribute only if you want to associate this monitor with a Run As profile.
|
|
TypeID
|
ManagementPack
IdentifierReference
|
Required
|
References a monitor type definition. The monitor must have configuration that validates to the schema for this monitor type
|
|
Confirm
Delivery
|
xsi:Boolean
|
Optional
|
TBC
|
In the Management Pack schema, the ParentMonitorID attribute is not required. However MPVerify will fail if it is not provided. There is only one monitor that is allowed to have this empty and that is the System.Health.EntityState monitor defined in the System.Health.Library MP.
Category
The category of a monitor must be one of the standard category strings. However for a monitor it is recommended that you use the same category as the overall aggregate monitor that it runs for. This will be one of the following:
-
AvailabilityHealth
-
PerformanceHealth
-
ConfiguraitonHealth
-
SecurityHealth
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.
Alert Settings
This is covered in a common section on this monitors page since it is the same for aggregate, dependency and unit monitors.
Operational States
This section defines operational states that map to the state of the monitor type. This allows the MP Author to customize the name and description of the state declared for the monitor type (the monitor type state ID). For example the monitor type to monitor if a Windows service is running on stopped may have two states called Running and Not Running. A monitor that is defined of this type must define two operational states that map to the monitor type states. In the case of SQL Server service monitoring these might be called SQL Service Running and SQL Service Stopped.
The monitor type definition does not declare how monitor type states map to health state (healthy, warning, error). It is up to the monitor to declare this mapping as it is dependent on the monitoring logic.
The monitor must have an operational state defined for each monitor type state. If this is not done, MPVerify will raise an error.
The operational state element 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.
|
|
MonitorType
StateID
|
ManagementPack
LocalIdentifierReference
|
Required
|
The monitor type state ID that this operational state is mapped to. This must be a valid state ID declared on the reference monitor type
|
|
HealthState
|
HealthState
|
Required
|
The health state for this operational state – this should be set to Warning, Error or Success
|
Here is an example declaration of operational states:
<OperationalStates>
<OperationalStateID="ComponentProblem"HealthState="Warning"MonitorTypeStateID="FirstEventRaised"/>
<OperationalStateID="ComponentOK"HealthState="Success"MonitorTypeStateID="SecondEventRaised"/>
</OperationalStates>
Each operational state can have a display string assigned in the language pack section of the MP. The monitor ID is the MPElement and the Operational State ID is the sub element. Therefore to define the display string for the ComponentProblem state above the following display string would be used if the monitor ID was Demo.EventBasedMonitor1:
<DisplayStringElementID="Demo.EventBasedMonitor1"SubElementID="ComponentProblem">
<Name>Component Error</Name>
<Description>The component is in an unhealthy state</Description>
</DisplayString>
Configuration
The configuration element must contain the necessary configuration for the monitor type that is being used. MPVerify will check this configuration. It is not possible for XML tools to verify the inner XML of the configuration element because this is a schema within a schema. The MP Schema allows any XML. Most monitor types will have different configuration schema requirements. For example the Microsoft.Windows.CheckNTServiceStateMonitorType in the Microsoft.Windows.Library MP requires two configuration elements – computer name and service name. The configuration section of a monitor would look something like:
<Configuration>
<ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<ServiceName>spooler</ServiceName>
</Configuration>
A different monitor type such as the System.Performance.AverageThreshold type in the System.Performance library requires a different configuration e.g.
<Configuration>
<ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
<CounterName>% Interrupt Time</CounterName>
<ObjectName>Processor</ObjectName>
<InstanceName>_Total</InstanceName>
<Frequency>120</Frequency>
<Threshold>10</Threshold>
<NumSamples>5</NumSamples>
</Configuration>