Enable Application Discovery
Aplica-se a: Operations Manager 2007 R2
The following topic describes the rule, data source, and module implementation necessary to perform discovery by using a management pack.
Discovery
Discovery is accomplished by using criteria that are based on the application structure and hosting relationships. In this topic, Operations Manager management pack contains a type of monitor called discovery. This monitor discovers a file, which is also a script. This script is later run to evaluate the availability of an application. It is possible to discover the application’s executable file, but typically, launching an application executable file does not provide any measureable information on health or availability.
Create a Discovery
When it is defined in a management pack, a discovery runs on every computer in the Operations Manager management group. In this case, an instance of the Microsoft.SCX.Sample.Application class is created only when the required script exists on the computer.
Notice that, in the discovery that is defined in the following code example, the <DiscoveryClass> is of a <TypeId> equivalent to Microsoft.SCX.Sample.Application and that the <DataSource> that is named <DS> has a <TypeID> of Microsoft.Unix.WSMan.TimedCommandExecution.DiscoveryData. The discovery class and data source are described in detail in following sections.
Within the data source definition, the <InvokeAction> named <ExecuteCommand> is defined. The <Input> for the invoke action includes the literal command line ls /tmp/SampleAppHealth.sh. In simple terms: the discovery performs the command ls with a parameter for a file in a specific directory on the system and stops if the time-out period is exceeded. The results from this command are passed to StdErr.
<Discoveries>
<Discovery ID="Microsoft.SCX.SampleApp.Discovery" Enabled="true" Target="Unix!Microsoft.Unix.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">
<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID="Microsoft.SCX.Sample.Application" />
</DiscoveryTypes>
<DataSource ID="DS" TypeID="Microsoft.Unix.WSMan.TimedCommandExecution.DiscoveryData">
<IntervalSeconds>30</IntervalSeconds>
<SyncTime />
<TargetSystem>$Target/Property[Type="Unix!Microsoft.Unix.Computer"]/NetworkName$</TargetSystem>
<Uri>https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx</Uri>
<Selector />
<InvokeAction>ExecuteCommand</InvokeAction>
<Input><![CDATA[ <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"><p:command>ls /tmp/SampleAppHealth.sh</p:command><p:timeout>10</p:timeout></p:ExecuteCommand_INPUT>]]></Input>
<FilterProperty>//*[local-name()="StdErr"]</FilterProperty>
<FilterValue>No such file or directory</FilterValue>
<ClassId>$MPElement[Name="Microsoft.SCX.Sample.Application"]$</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name="Unix!Microsoft.Unix.Computer"]/PrincipalName$</Name>
<Value>$Target/Property[Type="Unix!Microsoft.Unix.Computer"]/PrincipalName$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="Microsoft.SCX.Sample.Application"]/DisplayName$</Name>
<Value>Microsoft System Center Cross Platform Sample Application</Value>
</Setting>
</Settings>
</InstanceSettings>
</DataSource>
</Discovery>
</Discoveries>
In the Microsoft.SCX.Authoring.Guide.xml file that was created earlier, replace the </Discoveries> subsection under monitoring with the preceding XML.
Define a Class and Hosting Relationship
The next step in the discovery process is to define a class for the application and a hosting relationship for that class.
In the <EntityTypes> subsection, within the TypeDefinitions section, there is a place to define multiple <ClassTypes>. Define an individual <ClassType> to represent the sample application to be observed. Here it is named Microsoft.SCX.Sample.Application. This sample application matches a base class that is defined in the Microsoft.Unix.Library management pack, named Unix.ApplicationComponent.
For every <ClassType>, a <RelationshipType> must be defined that states where the class is to be hosted. In this case, a UNIX-based or Linux-based computer is the host. The base class is defined in the System.Hosting management pack. An individual <RelationshipType> is defined in <RelationshipTypes>, within the <EntityTypes> subsection, and within the <TypeDefinitions> section. Notice that the <Target> attribute matches the name of the <ClassType> that was defined earlier.
These definitions describe a class that has the following attributes:
An ID that is unique within the management pack.
A specialization of the UNIX Application Component class.
An external class, which can be referenced by other management packs if the management pack is sealed.
The class is hosted by another class (instances cannot exist without a host).
The following code example shows the XML:
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<ClassType ID="Microsoft.SCX.Sample.Application" Accessibility="Public" Abstract="false" Base="Unix!Microsoft.Unix.ApplicationComponent" Hosted="true" Singleton="false">
<Property ID="DisplayName" Type="string" Key="false" CaseSensitive="false" Length="256" MinLength="0" />
</ClassType>
</ClassTypes>
<RelationshipTypes>
<RelationshipType ID="Microsoft.Unix.ComputerHostsSampleApplication" Accessibility="Public" Abstract="false" Base="System!System.Hosting">
<Source>Unix!Microsoft.Unix.Computer</Source>
<Target>Microsoft.SCX.Sample.Application</Target>
</RelationshipType>
</RelationshipTypes>
</EntityTypes>
<ModuleTypes />
<MonitorTypes />
</TypeDefinitions>
In the Microsoft.SCX.Authoring.Guide.xml file that was created earlier, replace <TypeDefinitions/> with the preceding XML.
Define Data Source
In the discovery definition, <DataSource> references a <DataSourceModuleType> called Microsoft.Unix.WSMan.TimedCommandExecution.DiscoveryData, which must be defined.
All the attributes in this <DataSourceModuleType> are defined within <Configuration>. There are two attributes that can be changed. These modifiable attributes are defined in <OverrideableParameters> and are <IntervalSeconds> and <SyncTime>. Recall from the preceding discovery definition that <IntervalSeconds> is given a value of 30 seconds and <SyncTime> is left empty. Initial values for <OverrideableParameters> are set in discovery. <OverrideableParameters> can also be modified through the Operations console.
Because this is a discovery, you must make sure that the output is of the correct type. The last line before the closing tag, </DataSourceModuleType>, is an <OutputType> that is defined as System!System.Discovery.Data.
<ModuleTypes>
<DataSourceModuleType ID="Microsoft.Unix.WSMan.TimedCommandExecution.DiscoveryData" Accessibility="Public" Batching="false">
<Configuration>
<IncludeSchemaTypes>
<SchemaType>System!System.Discovery.MapperSchema</SchemaType>
</IncludeSchemaTypes>
<xsd:element name="IntervalSeconds" type="xsd:integer" />
<xsd:element name="SyncTime" type="xsd:string" />
<xsd:element name="TargetSystem" type="xsd:string" />
<xsd:element name="Uri" type="xsd:string" />
<xsd:element name="Selector" type="xsd:string" minOccurs="0" maxOccurs="1" />
<xsd:element name="InvokeAction" type="xsd:string" />
<xsd:element name="Input" type="xsd:string" />
<xsd:element name="FilterProperty" type="xsd:string" />
<xsd:element name="FilterValue" type="xsd:string" />
<xsd:element name="ClassId" type="xsd:string" />
<xsd:element name="InstanceSettings" minOccurs="0" maxOccurs="1" type="SettingsType" />
</Configuration>
<OverrideableParameters>
<OverrideableParameter ID="IntervalSeconds" Selector="$Config/IntervalSeconds$" ParameterType="int" />
<OverrideableParameter ID="SyncTime" Selector="$Config/SyncTime$" ParameterType="string" />
</OverrideableParameters>
<ModuleImplementation />
<OutputType>System!System.Discovery.Data</OutputType>
</DataSourceModuleType>
</ModuleTypes>
In the Microsoft.SCX.Authoring.Guide.xml file that you created earlier, replace <ModuleTypes/> in the TypeDefinitions section with the preceding XML. The module implementation details are described in the following section.
Module Implementation
The module implementation is defined within the data source module type section. Five <MemberModules> are defined: the <DataSource>, the <ProbeAction> and three <ConditionDectection> elements. Probe action is used in cross-platform management and is defined in Microsoft.Unix.Library. Scheduler is based on the Operations Manager Simple Scheduler. Scheduler takes two parameters, interval seconds and the sync time that is defined in the discovery Microsoft.SCX.SampleApp.Discovery. Five parameters are passed to probe action: the target system, the uri, the selector that was defined earlier in the data source module type Microsoft.Unix.WSMan.TimedCommandExecution.DiscoveryData, and the invoke action and input, which are defined in the discovery Microsoft.SCX.SampleApp.Discovery.
The condition detection elements are <ErrorFilter>, <Filter>, and <Mapper>. Error filter receives any WS-Management errors, which validate that a connection to the computer exists. Filter takes the results from the probe action and checks that the filter value, which is defined in discovery as “No such file or directory”, does not match. In this case, there is no need for a complex parsing of the probe action result. The file is either there or it is not. The filter succeeds if the result is anything other than “No such file or directory”. Mapper describes how to map the data of the class instance, class ID, and instance setting.
Composition describes the order in which to execute each of the member modules. When the discovery is run, the composition in the data source module type describes when and how to perform the actions. The scheduler determines when the probe action is to be run. After the probe action is run, the results are checked by the error filter to make sure that a valid connection exists. Then, the filter is checked to make sure that the file is present. Finally, if the file is present, mapper takes the validated discovery and maps the class ID and instance settings.
<ModuleImplementation Isolation="Any">
<Composite>
<MemberModules>
<DataSource ID="Scheduler" TypeID="System!System.SimpleScheduler">
<IntervalSeconds>$Config/IntervalSeconds$</IntervalSeconds>
<SyncTime>$Config/SyncTime$</SyncTime>
</DataSource>
<ProbeAction ID="Invoke" TypeID="Unix!Microsoft.Unix.WSMan.Invoke.ProbeAction">
<TargetSystem>$Config/TargetSystem$</TargetSystem>
<Uri>$Config/Uri$</Uri>
<Selector>$Config/Selector$</Selector>
<InvokeAction>$Config/InvokeAction$</InvokeAction>
<Input>$Config/Input$</Input>
</ProbeAction>
<ConditionDetection ID="ErrorFilter" TypeID="System!System.ExpressionFilter">
<Expression>
<Not>
<Expression>
<Exists>
<ValueExpression>
<XPathQuery Type="String">WsManData/ErrorCode</XPathQuery>
</ValueExpression>
</Exists>
</Expression>
</Not>
</Expression>
</ConditionDetection>
<ConditionDetection ID="Filter" TypeID="System!System.ExpressionFilter">
<Expression>
<RegExExpression>
<ValueExpression>
<XPathQuery Type="String">$Config/FilterProperty$</XPathQuery>
</ValueExpression>
<Operator>DoesNotContainSubstring</Operator>
<Pattern>$Config/FilterValue$</Pattern>
</RegExExpression>
</Expression>
</ConditionDetection>
<ConditionDetection ID="Mapper" TypeID="System!System.Discovery.ClassSnapshotDataMapper">
<ClassId>$Config/ClassId$</ClassId>
<InstanceSettings>$Config/InstanceSettings$</InstanceSettings>
</ConditionDetection>
</MemberModules>
<Composition>
<Node ID="Mapper">
<Node ID="Filter">
<Node ID="ErrorFilter">
<Node ID="Invoke">
<Node ID="Scheduler" />
</Node>
</Node>
</Node>
</Node>
</Composition>
</Composite>
</ModuleImplementation>
In the Microsoft.SCX.Authoring.Guide.xml file that was created earlier, replace <ModuleImplementation/>, in the DataSourceModuleType for Microsoft.Unix.WSMan.TimedCommandExecution.DiscoveryData, with the preceding XML code example.
Observe Discovery
To observe the discovery function within Operations Manager, save the file Microsoft.SCX.Authoring.Guide.xml and import the management pack into the management group, as described in Required Management Pack Definitions.
Initially, verify that an instance of the class is not discovered because the script that is defined in the discovery is not present on the computer. Wait approximately 30 seconds for configuration to be sent to the UNIX-based or Linux-based computer that you are monitoring. Open the System Center Operations console and go to the discovered Inventory view in the monitoring node. This view shows all discovered instances of a particular type.
Change the target type
Right-click the computer name and select Change Target Type.
Select Microsoft.SCX.Sample.Application.
Click OK.
There should be no objects in the list view because nothing has been discovered.
To observe a successful discovery, copy the SampleAppHealth.sh script file to the /tmp folder on the UNIX-based or Linux-based computer. This script simulates the monitoring of the health of an application or service. In this case, this script echoes a value to StdErr, but it might be checking to see if an application or a file exists. Change the permissions of the script by executing the chmod command, as follows: chmod 755 SampleAppHealth.sh
Install the sample scripts
Create a SampleScripts folder at the root level of the Operations Manager management server (%SYSTEMDRIVE%).
Copy the SampleAppHealth.sh and SampleAppPerf.sh scripts to the SampleScripts folder.
Copy the SampleAppHealth.sh and SampleAppPerf.sh scripts to the /tmp folder on the UNIX-based or Linux-based computer.
On the UNIX-based or Linux-based computer, change the permissions of the files by using the **chmod 755 filename **for both files.
Wait approximately 30 seconds, and then refresh the view by pressing F5. An instance of the class will appear.
Open the properties of this object by right-clicking the computer name and then selecting properties. The name, path, and display name properties are displayed.
Notice that the state is “Not Monitored” and that there is an empty circle. This occurs because only a discovery has been created, but no monitoring, rules, or alerts currently exist.
For another view from the monitoring node, select Unix/Linux Servers. The computer state is healthy and the circle has a green check mark. This view shows overall health.
Right-click the computer name, and then select Open: Diagram View. A new view is opened.
The health of the computer is determined by the active monitors that are targeted at the system: File System, Network and Operating System. The Microsoft.SCX.Sample.Application is targeted but is not active and currently does not report health information for the computer.
Customizing Discovery
Every discovery must have the following objects defined in the management pack:
Discovery monitor
Class
Hosting relationship
Data source
To reuse this sample discovery, there are two locations in which to make changes. Both are in the discovery monitor, Microsoft.SCX.SampleApp.Discovery.
Currently <IntervalSeconds> is set to 30 seconds. In an actual production environment, this value would typically be set to one hour (3600 seconds). Setting <IntervalSeconds> for a longer period might reduce load on the network, but it also means that it might take as long as the maximum <IntervalSeconds> for any new computer to be discovered. For the purposes of this authoring guide, the interval is short.
<IntervalSeconds>30</IntervalSeconds>
The input for the <InvokeAction> is wrapped with CDATA tags and in XML format following the CIM schema. Change the value of command to change the location or name of the file that is used for discovery. The UNIX command to list directory contents is ls. The path to the file is /tmp, defaulting to the system root as the path parent. The file that is used in this example is a BASH script.
<Input>
<![CDATA[
<p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem">
<p:command>ls /tmp/SampleAppHealth.sh</p:command>
<p:timeout>10</p:timeout>
</p:ExecuteCommand_INPUT>
]]>
</Input>
The file that is used for discovery can be a text file or a script. It is useful to use a script that can also be executed to provide additional system information. In the next topic on monitoring, the output of this script will be used to simulate application health.