Operations Manager – Extending UNIX/Linux Monitoring with MP Authoring – Part I

Introduction

The OpsMgr UNIX and Linux monitoring implementation can be extended through MP authoring to implement robust system and application monitoring for UNIX/Linux servers.   The most direct mechanism of extension comes in the form of the script provider, accessed with WSMan Invoke modules.   The WSMan Invoke modules support three methods of invoking actions:

• ExecuteCommand – execute a command (e.g. a script already on the file system ) and return the results
• ExecuteShellCommand – execute a command through sh (with pipeline support) and return the results
• ExecuteScript  – download and execute an embedded script and return the results

Of these three methods, I prefer to use ExecuteShellCommand in most cases, as it allows for the use of complex one-liner shell commands, embedded in the MP.

In a series of posts, I will describe the creation of an example Management Pack for monitoring an application, featuring dynamic application discovery, discovery of multiple log files, and advanced monitoring implementations.

Example Application Details

The example MP described in these blog posts implements monitoring for a hypothetical application (MyApp).  The application involves a daemon, a set of log files, and application performance counters where the metrics are accessible as the contents of files.

Part I – Discovering an Application

Setting up the MP

I am a big fan of the R2 Authoring Console and will be using it to create this example MP.   The first step then is to create a new MP in the Authoring Console (ID:  MyApp.Monitoring).    Once the MP is created and saved, references are needed.   References I am adding are:

• Microsoft.Unix.Library – contains UNIX/Linux classes and modules
• Microsoft.SystemCenter.DataWarehouse.Library – required for publishing performance data to the DW
• System.Image.Library – contains icon images referenced in class definition

Configuring the Base Composite Modules

Most monitoring and discovery workflows used in this MP example will involve the execution of a shell command through the Microsoft.Unix.WSMan.Invoke.ProbeAction ExecuteShellCommand method.   Therefore, setting up a new composite probe action and a couple of base data sources will make further module implementation much simpler.

Probe Action:  MyApp.Monitoring.ProbeAction.ShellCommand

This probe action simply wraps the Microsoft.Unix.WSMan.Invoke.ProbeAction in a way that makes it easier to use for shell command execution.

Configuration Parameters:

• TargetSystem (string)  – the UNIX/Linux agent computer that will execute the command
• ShellCommand (string) – the shell command to execute
• Timeout (integer) – the command timeout, in seconds

Member Modules:

This probe action will only include one member module:  Microsoft.Unix.WSMan.Invoke.ProbeAction.  The configuration of the module looks like:

<TargetSystem>$Config/TargetSystem$</TargetSystem>
<Uri>
http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/
 SCX_OperatingSystem?__cimnamespace=root/scx
</Uri>
<Selector/>
<InvokeAction>ExecuteShellCommand</InvokeAction>
<Input>
<p:ExecuteShellCommand_INPUT xmlns:p="http://schemas.
 microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem">
<p:command>$Config/ShellCommand$</p:command>
<p:timeout>$Config/Timeout$</p:timeout>
</p:ExecuteShellCommand_INPUT>
</Input>

Note that the configuration parameters for ShellCommand and Timeout are embedded in the “Input” parameter XML fragment.

Data Source: MyApp.Monitoring.DataSource.ShellCommandMonitoring

The probe action created in the previous step will be used in a number of monitoring workflows, so creating a data source that combines the probe action with a scheduler will make monitoring workflow configuration simpler.

Configuration Parameters:

• Interval (integer) – timer interval in seconds
• TargetSystem (string)  – passed to the probe action module
• ShellCommand (string) – passed to the probe action module
• Timeout (integer) – passed to the probe action module

Member Modules:

The first module in this composite data source is a System.Scheduler module, with a basic configuration:

<Scheduler>
<SimpleReccuringSchedule>
<Interval>$Config/Interval$</Interval>
<SyncTime/>
</SimpleReccuringSchedule>
<ExcludeDates/>
</Scheduler>

This scheduler module is followed by the ShellComand probe action, with the configuration:

<TargetSystem>$Config/TargetSystem$</TargetSystem>
<ShellCommand>$Config/ShellCommand$</ShellCommand>
<Timeout>$Config/Timeout$</Timeout>

Data Source: MyApp.Monitoring.DataSource.ShellCommandDiscovery

This data source is identical to the MyApp.Monitoring.DataSource.ShellCommandMonitoring data source, except it features a System.Discovery.Scheduler scheduler module instead of a System.Scheduler module.  Discovery workflows must use a Discovery scheduler in order to prevent problems with cookdown (i.e. discovery workflows ‘cooking-down’ along with monitoring workflows).   So this data source combines the ShellCommand probe action with a Discovery scheduler.

Additionally, I have added a System.ExpressionFilter module to the ShellCommandDiscovery data source to prevent the discovery workflows from continuing if an error is encountered (either WSMan error or ShellCommand StdErr output).   The ExpressionFilter configuration is:

<Expression>
<And>
<Expression>
<RegExExpression>
<ValueExpression>
 <XPathQuery>//*[local-name()="StdErr"]</XPathQuery>
</ValueExpression>
 <Operator>DoesNotMatchRegularExpression</Operator>
 <Pattern>^.+</Pattern>
 </RegExExpression>
 </Expression>
<Expression>
<Not><Expression><Exists>
<ValueExpression>
 <XPathQuery>WsManData/ErrorCode</XPathQuery>
</ValueExpression>
</Exists> </Expression> </Not>
</Expression>
</And>
</Expression>

Class Definition

With the base composite modules configured, we can move on to the actual application discovery, starting with the definition of the application class.  The Microsoft.Unix.LocalApplication is an ideal base class for the application class, and already has a hosting relationship defined so that Microsoft.Unix.Computer hosts Microsoft.Unix.LocalApplication.

Class Definition:

• ID:  MyApp.Monitoring.MyApp
• Base Class:  Microsoft.Unix.LocalApplication
• Name:  MyApp

Properties:

• Name (String) – Key
• InstallPath (String)

Discovering the Application

When discovering a Windows application in OpsMgr, we would typically use a registry probe.  In UNIX/Linux application discovery, probing the existence or contents of a file is typically the most effective way to identify the instance of an application.   In this example, the MyApp application has a configuration file named: myapp.conf in the installation path of /opt/myapp.  Thus, a shell command:  ls /opt/myapp/myapp.conf | wc –l would return a 1 if the file exists, or 0 if the file doesn’t exist.   We can use this logic in the application discovery.

Discovery Data Source: MyApp.Monitoring.DataSource.MyAppDiscovery

To implement this application discovery, I will create a new data source, building on the ShellCommandDiscovery data source previously created.

Configuration Parameters:

• Interval (integer):  Scheduler interval in seconds
• TargetSystem (string):  UNIX/Linux agent computer to execute the discovery
• AppPath (string):  File system path to the application, overrideable

Member Modules:

The first module in this data source is the ShellCommandDiscovery data source (MyApp.Monitoring.DataSource.ShellCommandDiscovery).   This will be used to query the file system for the application configuration file, to determine if the app is present.  The configuration for this module is:

<Interval>$Config/Interval$</Interval>
<TargetSystem>$Config/TargetSystem$</TargetSystem>
<ShellCommand>
 ls $Config/AppPath$/myapp.conf | wc -l
</ShellCommand>
<Timeout>120</Timeout>

In order to return discovery data from this data source, a Discovery Mapper module is required.   In this case, I will use a System.Discovery.FilteredClassSnapshotDataMapper module to filter the results (only return discovery data if the app is found).   An output of 1 from the shell command indicates that the configuration file was found, while an output of 0 indicates that the configuration file was not found.  The configuration for the FilteredClassSnapShotDataMapperModule would be:

<Expression>
<SimpleExpression>
<ValueExpression>
 <XPathQuery Type="String">
  //*[local-name()="StdOut"]
 </XPathQuery>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
 <Value Type="String">1</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
<ClassId>
 $MPElement[Name='MyApp.Monitoring.MyApp']$
</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>
$MPElement[Name='MyApp.Monitoring.MyApp']/Name$
</Name>
<Value>MyApp</Value>
</Setting>
<Setting>
<Name>
 $MPElement[Name='MyApp.Monitoring.MyApp']/InstallPath$
</Name>
<Value>$Config/AppPath$</Value>
</Setting>
<Setting>
<Name>
 $MPElement[Name='System!System.Entity']/DisplayName$
</Name>
<Value>MyApp - $Config/TargetSystem$</Value>
</Setting>
<Setting>
<Name>
 $MPElement[Name='MicrosoftUnixLibrary!
 Microsoft.Unix.Computer']/PrincipalName$
</Name>
<Value>$Config/TargetSystem$</Value>
</Setting>
</Settings>
</InstanceSettings>

Note that the Key Property (PrincipalName) for the hosting Microsoft.Unix.Computer object is included in the DiscoveryData.

Discovery Rule:  MyApp.Monitoring.Discovery.MyApp

With the discovery data source implemented, finishing the discovery just requires creation of the discovery rule, which targets Microsoft.Unix.Computer objects.

Data Source Configuration:

• Interval:  14400
• TargetSystem: $Target/Property[Type=”MicrosoftUnixLibrary!Microsoft.Unix.Computer”]/PrincipalName$
• AppPath: /opt/myapp

This is a good time to create the MP’s presentation folder and a state view targeting MyApp objects.   Once the discovery has executed, discovered instances of the app can be viewed in the state view or Discovered Inventory view:

Stay tuned for more posts on completing this example Management Pack