Operations Manager Cross-Platform Authoring: Invoke Action Monitor

When monitoring UNIX/Linux servers, command execution or script-based monitors can provide a great deal of flexibility in many health-checking applications.   The Operations Manager 2007 R2 cross-platform agent facilitates the execution of shell command lines or executable binaries and scripts with the Microsoft.Unix.WSMan.Invoke.Probe module.   In this post, I will walk through the use of this module in an example monitoring scenario:  monitoring UNIX/Linux systems for the count of defunct/zombie processes.   The management pack described in this post can be downloaded here.

Background

The Microsoft.Unix.WSMan.Invoke.Probe is a nicely wrapped implementation of the module Microsoft.SystemCenter.WSManagement.TimedInvoker from the Microsoft.SystemCenter.WsManagement.Library management pack.  The Microsoft.Unix.WSMan.Invoke.Probe facilitates the execution of commands or processes on the agent with two Invoke Actions:  ExecuteCommand and ExecuteShellCommand.   The ExecuteCommand Invoke Action executes a script or binary executable (along with command line parameters), whereas the ExecuteShellCommand executes a command string in a shell environment.   While similar, a key functional difference between the two is that the ExecuteShellCommand Invoke Action supports command-line pipe operations while the ExecuteCommand Invoke Action does not.   So, any output filtering with awk, sed, or grep (for example) will require the use of the ExecuteShellCommand Invoke Action.  An example of using the ExecuteCommand Invoke Action in a discovery and monitor can be found in the Cross Platform MP Authoring Guide.   However, one advantage of using ‘one-liner’ commands with the ExecuteShellCommand Invoke Action in monitoring scenarios as opposed to calling local scripts with ExecuteCommand is that the need to distribute and maintain scripts to agents is eliminated and the monitoring script is thus embedded in the MP to be managed centrally. 

As for monitoring of defunct processs count, the UNIX ps command can easily be utilized to identify defunct/zombie processes.  With some output manipulation by grep and awk, the command string can be configured to return just the number of defunct processes to StdOut: ps -eo ‘s’ | grep Z | awk ‘END{print NR}’

Turning this command into a functional monitor then just requires a data source to execute the InvokeAction, a monitor type to define the condition detections and health states, and a unit monitor.

Walk Through

 1:  Create a new management pack in the authoring console.  In this case, I am calling the management pack:  UNIX Custom Monitors with the id: UNIX.Custom.

2: Add management pack references. In this example, the referenced class and data source are both made available through a reference to the Microsoft.Unix.Library, so it is the only additional reference that I have specified.   Additional references could be added to the Microsoft.SystemCenter.DataWarehouse.Library MP if performance data were going to be collected, or specific operating system management packs if those classes were required.

3A:  Create the data source. 

3B: Add data source Configuration Parameters.   The parameters that will be required for the Scheduler and Invoke probe modules by this data source are.

• Interval – Integer (Overridable)
• TargetSystem – String
• InvokeAction – String
• Selector – String
• Uri – String
• Input – String

3C: Create the System.Scheduler data source member module, using the Interval configuration parameter to control the interval.

3D: Create the Invoke Probe member module (module type:  Microsoft.Unix.WSMan.Invoke.Probe).

3E:  Add an Expression Filter member module to filter errors.

3F:  Link the Data Source member modules in order.

4A:  Create the Monitor Type (note:  there is no need to worry about the runas account in these workflows, as the Microsoft.Unix.WSMan.Invoke.Probe has the standard Cross Platform RunAs accounts already configured.  There is an additional module that provides the same funtionality but utilizes the Privileged RunAs profile).

• The TargetSystem will be provided from the Network Name property of the monitor target. 
• The Uri value is the standard SCX Uri: http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx.  
• In this case, the Selector is not required.  
• The InvokeAction parameter is: ExecuteShellCommand.  
• The input is a bit of XML that embeds the command string to invoke: 

<p:ExecuteShellCommand_INPUT xmlns:p=”http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem”&gt;

<p:command>ps -eo ‘s’ | grep Z | awk ‘END{print NR}’</p:command>

<p:timeout>25</p:timeout>

</p:ExecuteShellCommand_INPUT>

<DataItem type=”Microsoft.SystemCenter.WSManagement.WSManData“time=”2010-02-04T11:30:41.1785581-05:00“sourceHealthServiceId=”913F69B3-DD39-1779-6080-9377BD649872“>

<WsManData>

<n1:ExecuteShellCommand_OUTPUT xml:lang=” “>

 <n1:ReturnCode>0</n1:ReturnCode>

 <n1:StdOut>0 </n1:StdOut>

 <n1:StdErr/>

 <n1:ReturnValue>true</n1:ReturnValue>

 </n1:ExecuteShellCommand_OUTPUT>

 </WsManData>

 </DataItem>

 By overriding the default threshold  and setting a threshold of zero, the monitor can easily be tested: