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


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:

<p:ExecuteShellCommand_INPUT xmlns:p="http://schemas.

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:


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


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:

</Exists> </Expression> </Not>

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
  • 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:

 ls $Config/AppPath$/myapp.conf | wc -l

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:

 <XPathQuery Type="String">
 <Value Type="String">1</Value>
<Value>MyApp - $Config/TargetSystem$</Value>

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


About Kristopher Bash
Kris is a Senior Program Manager at Microsoft, working on UNIX and Linux management features in Microsoft System Center. Prior to joining Microsoft, Kris worked in systems management, server administration, and IT operations for nearly 15 years.

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

  1. Mark Stone says:


    I hope you are well.

    This blog is exactly what I was looking for. I followed your instructions to the letter and tried out the Management Pack created in Part I. Unfortunately I had no joy in discovering the file I specified (I was using the SCOM Agent directory as a test) and I did not receive a 1 or a 0 response from the ls command. Maybe I did not create the datasources correctly or maybe it was the discovery rule. I have checked this 4 times and it all seems right.

    I know this is a cheeky request, but do you have an original xml of the work you describe above. A copy of my xml is below:

    – – – MyApp.Monitoring MyApp.Monitoring – – Microsoft.SystemCenter.DataWarehouse.Library 6.1.7221.0 31bf3856ad364e35 – Microsoft.SystemCenter.Library 6.1.7221.0 31bf3856ad364e35 – Microsoft.SystemCenter.WSManagement.Library 6.1.7221.0 31bf3856ad364e35 – Microsoft.Unix.Library 6.1.7000.256 31bf3856ad364e35 – Microsoft.Windows.Library 6.1.7221.0 31bf3856ad364e35 – System.Health.Library 6.1.7221.0 31bf3856ad364e35 – System.Library 6.1.7221.0 31bf3856ad364e35 – System.Performance.Library 6.1.7221.0 31bf3856ad364e35 – – – – – – – – – – – $Config/Interval$ $Config/TargetSystem$ ls $Config/AppPath$/setup.sh | wc -l 120 – – – – //*[local-name()=”StdOut”] Equal – 1 $MPElement[Name=’MyApp.Monitoring.MyApp’]$ – – – $MPElement[Name=’MyApp.Monitoring.MyApp’]/Name$ MyApp – $MPElement[Name=’MyApp.Monitoring.MyApp’]/InstallPath$ $Config/AppPath$ – $MPElement[Name=’System!System.Entity’]/DisplayName$ MyApp – $Config/TargetSystem$ – $MPElement[Name=’MicrosoftUnixLibrary!Microsoft.Unix.Computer’]/PrincipalName$ $Config/TargetSystem$ – – System!System.Discovery.Data – – – – – – – – $Config/Interval$ – $Config/TargetSystem$ $Config/ShellCommand$ $Config/Timeout$ – – – – – – //*[local-name()=”StdErr”] DoesNotMatchRegularExpression ^.+ – – – – – WsManData/ErrorCode – – – SystemCenter!Microsoft.SystemCenter.WSManagement.WSManData – – – – – – – – $Config/Interval$ – $Config/TargetSystem$ $Config/ShellCommand$ $Config/Timeout$ – – SystemCenter!Microsoft.SystemCenter.WSManagement.WSManData – – – – – – $Config/TargetSystem$ http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx ExecuteShellCommand –
    – SystemCenter!Microsoft.SystemCenter.WSManagement.WSManData System!System.BaseData – – – Discovery – – 300 $Target/Property[Type=”MicrosoftUnixLibrary!Microsoft.Unix.Computer”]/PrincipalName$ /opt/microsoft/scx/bin – – – Custom – – – – – MyApp – MyApp.Monitoring.DataSource.MyAppDiscovery – MyApp.Monitoring.DataSource.ShellCommandDiscovery – MyApp.Monitoring.DataSource.ShellCommandMonitoring – MyApp – MyApp – MyApp.Monitoring.ProbeAction.ShellCommand – – – MyApp – MyApp.Monitoring.DataSource.MyAppDiscovery – MyApp.Monitoring.DataSource.ShellCommandDiscovery – MyApp.Monitoring.DataSource.ShellCommandMonitoring – Discovery MyApp – MyApp – MyApp – MyApp.Monitoring.ProbeAction.ShellCommand

    I am stuck and would appreciate any assistance.



  2. Alex says:


    I’m just trying to do exactly that “ExecuteScript – download and execute an embedded script and return the results” but I can’t find any documentation about this. Can you point me to the right direction?


  3. Erez says:

    Hello Kristopher ,
    these solutions for unix monitoring look great, it’s exactly what I am looking for. When I went to the authoring console to make the mp(Part I – Discovering an Application) –
    I can’t seem to be able to go through the following part(Creating the Microsoft.Unix.WSMan.Invoke.ProbeAction Configuration):






    Do you know any reason why would it not compile?

    Thanks ahead,

  4. Peter says:

    Hi, I tried to follow this procedure, but it already fails on creating the Probe Action. The input field cannot contain a child element like this because the parent model is text only.
    Or something like that.
    Any idea’s?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: