Data Item XML - MonitorTaskDataType

This data type is used as input for recovery task. Recovery can be executed on diagnostic or it can be executed on the state change where later is always present because diagnostic is always associated with state change of monitor. Because this is input data item, $Data/…$ context parameter replacement can be used and XPath queries can be created easier once we discuss its XML representation.

<DataItem type="MonitorTaskDataType" time="2007-03-11T15:15:19.0249088-07:00" >

    <StateChange>

        <DataItem time="2007-03-11T15:15:17.5561588-07:00" type="System.Health.MonitorStateChangeData">

            <ManagedEntityId>05A3B5C7-2A5A-F3A6-B7A6-51CD4A300779</ManagedEntityId>

            <EventOriginId>2875EBE8-6F9D-4740-A540-B5D98E36A087</EventOriginId>

            <MonitorId>A276C9DE-DE5B-08E9-EC15-DCD7FA317478</MonitorId>

            <ParentMonitorId>040E606C-6330-7245-F49D-A2E70A78177E</ParentMonitorId>

            <HealthState>2</HealthState>

            <OldHealthState>1</OldHealthState>

            <TimeChanged>2007-03-11T15:15:17.5561588-07:00</TimeChanged>

            <Context>

This part will always carry a data item which caused state change in the first place if this is indeed a state change for unit monitor. It is empty for all other monitors (aggregate rollup and dependency rollup). State change trigger is another data type so internal XML fragment will represent its XML representation and will start with <DataItem>. Following is representation of event data type.

                <DataItem type="Microsoft.Windows.EventData" time="2007-03-11T15:14:53.0000000-07:00">

                    <EventOriginId>{F0DC0745-EC0C-4255-846C-C8C82549A559}</EventOriginId>

                    <PublisherId>{431AD5B9-DD73-ADE6-7A14-B407799A13DC}</PublisherId>

                    <PublisherName>Sample Publisher</PublisherName>

                    <Channel>Application</Channel>

                    <LoggingComputer>Computer</LoggingComputer>

                    <EventNumber>2147503670</EventNumber>

                    <EventCategory>0</EventCategory>

                    <EventLevel>1</EventLevel>

                    <UserName>N/A</UserName>

                    <RawDescription><![CDATA[This is sample event for %1]]></RawDescription>

                    <LCID>1033</LCID>

                    <CollectDescription Type="Boolean">true</CollectDescription>

                    <Params>

                        <Param>SampleComputer</Param>

                    </Params>

                    <EventData/>

                    <EventDisplayNumber>20022</EventDisplayNumber>

                    <EventDescription><![CDATA[This is sample event for SampleComputer]]></EventDescription>

                </DataItem>

            </Context>

        </DataItem>

    </StateChange>

    <Diagnostic>

This whole section exists when recovery is executed on Diagnostic. It will always carry a data item which was produced by diagnostic if there is indeed one created.In that case it will start with <DataItem>. And again, XPath can be created to access values of its particular properties.

    </Diagnostic>

</DataItem>

XPath to properties:

State change and especially its trigger is most of the time data item which might be interesting to use. To get to the properties of the trigger, one must always type following:

$Data/StateChange/DataItem/Context/DataItem/< relative path to the property>$

Sometimes diagnostic can produce a data item which can be later used inside of recovery, especially if recovery actions should be based on the Boolean expression comparing diagnostic output against some values. It this case it is possible for diagnostic to produce a property bag data type and one should always use following:

$Data/Diagnostic/DataItem/ Property[@Name=’<name of the property>’]

Comments

• Anonymous
  November 21, 2007
  I started series describing some of the data items floating thru the workflows of Operations Manager