Extending the Cross Platform Monitoring Agent in Operations Manager 2007 R2

Written by Neil Harrison, Premier Field Engineer.

When System Center Operations Manager 2007 R2 (OpsMgr) was released, one of the most interesting new features was the addition of Cross Platform monitoring or, in other words, Unix/Linux monitoring. Having been involved with Enterprise monitoring for almost a decade now I was really intrigued by what OpsMgr could do in this area.

It turns out there is a decent amount of monitoring data returned by the Cross Platform agent and it may very well be enough for many organizations. However, any organization that has a reasonably sized Unix/Linux infrastructure is inevitably going to need more from their monitoring solution then what OpsMgr is offering out of the box. This is the same no matter what monitoring tool your organization is using. Solving this issue for the Windows agent is relatively easy with OpsMgr as there is a Unit Monitor type already defined for creating a script based monitor (scripting knowledge required). But Unix/Linux admins aren’t as lucky as there is nothing immediately available in the Authoring Console for doing this on a Cross Platform agent.

It turns out that there is an excellent Cross Platform Authoring Guide available which walks you through the process of creating various monitor types for scripts as well as how to configure them for script based monitoring. The problem is that it is all in XML and not immediately intuitive to anybody who is not familiar or comfortable with creating Management Packs in XML directly.

As a result, I wanted to provide 3 things with this article:

1. A simple “starter” Management Pack that includes the basic monitoring types already defined for creating script-based monitoring on Cross Platform agents. This Management Pack can be opened using the Authoring Console and all that is needed is to create the actual unit monitors. It is my opinion that the knowledge needed to create the actual monitor type is usually beyond what’s needed for an OpsMgr admin so why not have it pre-created like we have for the Windows unit monitors.
2. I wanted to illustrate how to create script-based monitoring in the Authoring Console for Cross-Platform agents. This is all based on the same information provided in the Cross Platform Authoring Guide but I am doing it through the Authoring Console as opposed to raw XML.
3. I wanted to illustrate that it is possible to use a scripting language like PERL to enhance your Cross Platform monitoring and basically monitor almost anything. If it can be scripted in PERL then you can monitor it in OpsMgr. I’m assuming that anybody who has done a reasonable amount of Unix/Linux administration is well-acquainted with PERL.

So let’s get started. I’m going to illustrate how to create a simple “health” monitor as well as a simple “performance threshold” monitor.

There are two MPs included with this post. One contains just the monitoring type definitions which you can use in your own environment. The second contains the same type definitions but also the monitors I’ve created in this post. The second MP also includes a simple performance collection rule so that you can view custom performance data both through reports as well as a view if you wanted to define one.

Scenario #1: Creating a Simple Cross Platform Health Monitor

Let’s assume that I’ve been tasked with keeping track of whether a certain file exists on my system. I want to create a monitor that is in Critical condition when the file does not exist and is Healthy when it does exist. As a result, I created the following simple PERL script:

#!/usr/bin/perl

$file = $ARGV[0];

# In case the parameter wasn't specified through an override

if ($file eq "") {

$file = "/tmp/myfile.log";

}

if (-e $file) {

print STDERR "OK";

} else {

print STDERR "Error";

}

The logic is pretty simple. I run the script and pass a file that I want to check. If it exists, I return “OK” to STDERR and if it doesn’t I return “Error” to STDERR. STDERR is where the MonitorType definition is pre-configured to expect its output. So let’s create a monitor to use this information:

1. Open our Custom Cross Platform MP in the OpsMgr R2 Authoring Console.

Note: The name of the MP file has to match the name defined in the Identity tags within your MP XML file so if you rename the MP you’ll want to rename both so that they match.

2. If you are prompted that a referenced Management Pack was not found then you may need to browse to that MP file and select it. You may see this with the Microsoft.SystemCenter.Internal MP which can be found in the Install Directory for OpsMgr (C:\Program Files\System Center Operations Manager)

3. If required, go to File –>Properties and add any MP references that you might need for targeting your monitors. It’s recommended to narrow down your target as much as possible so if you are targeting SUSE Linux then reference that particular MP so you can target the SUSE Linux Computer class for your monitor as opposed to all Unix Computers.

4. Select Health Model in the “wunderbar” in the bottom left and go to Monitors.

5. Right-click the empty white space and select New->Custom Unit Monitor

6. In the Choose A Unique Identifier dialog box replace “NewUnitMonitor” with something meaningful for your monitor such as “CheckFileExistence”

7. On the General tab for the new monitor fill in the following fields:

• Name: This is a friendly name for your monitor that will be displayed in the OpsMgr console
• Target: This is the object class that you will be targeting for your monitor. Choose whatever is the most selective for your monitor (i.e.. SUSE Linux Computer)
• Parent Monitor: Choose the aggregate rollup monitor that you want this monitor to fall under. This will affect how your monitor is displayed in Health Explorer and to what the health state flows up to.

8. On the Configure tab choose “Browse for a type…” and select Custom.CrossPlatform.Monitoring.RunScript.MonitorType” which is a Monitor Type that was already created in the MP.

9. Once you have selected the MonitorType the Configuration tab will change and you will need to fill in the following fields:

• TargetSystem: Enter the following $Target/Host/Property[Type=”Unix!Microsoft.Unix.Computer”]/NetworkName$. This is a variable that will be replaced automatically with the name of the Unix server at the time the monitor is run.
• Command: This is the absolute path of my PERL script as well as the absolute path of the file I want to check as a parameter (i.e. /tmp/checkForFile.pl myfile.log)
• Interval: This is how often you want the monitor to run the script.

10. On the Health tab configure the health states. The MonitorType definition actually specifies 3 possible health states which is why we see 3 here. Our script only utilizes 2 however.

11. On the Alerting tab check the option to Generate Alerts if needed and enter an appropriate subject line and description

12. On the options page change the Accessibility to Public.

That’s it! You’ve just created a monitor that will run the script located at /tmp/checkForFile.pl every 30 seconds and based on the string returned to STDERR it will set the health state accordingly. If you wanted to add a Warning state you could do that as well by returning the string “Warning” to STDERR.

Scenario #2: Creating a Cross Platform Performance Monitor

In this scenario, let’s assume that I’ve been tasked with keeping track of the number of files in a certain directory. If the amount of files exceeds a specified amount then that is a Critical condition. Otherwise, it should have a Healthy state. As a result, I created the following simple PERL script:

#!/usr/bin/perl

my $dir = $ARGV[0];

chdir $dir;

my @files = <*>;

my $fileCount = @files;

print STDERR $fileCount;

Again, the logic is pretty simple. I run the script and pass a directory that I want to check. I check the amount of files in that directory and then pass the amount back to STDERR where our monitor will be looking for it. So let’s create a monitor to check this one as well:

1. Select Health Model in the “wunderbar” in the bottom left and go to Monitors.

2. Right-click the empty white space and select New –>Custom Unit Monitor

3. In the Choose A Unique Identifier dialog box replace “NewUnitMonitor” with something meaningful for your monitor such as “CheckFileCount”

4. On the General tab for the new monitor fill in the following fields:

• Name: This is a friendly name for your monitor that will be displayed in the OpsMgr console
• Target: This is the object class that you will be targeting for your monitor. Choose whatever is the most selective for your monitor (e.g. SUSE Linux Computer)
• Parent Monitor: Choose the aggregate monitor that you want this monitor to fall under. This will affect how your monitor is displayed in Health Explorer and to what the health state flows up to.

5. On the Configure tab choose “Browse for a type…” and select Custom.CrossPlatform.Monitoring.Threshold.MonitorType” which is a Monitor Type that was already created in the MP.

6. Once you have selected the MonitorType the Configuration tab will change and you will need to fill in the following fields:

• IntervalSeconds: This is the interval for how often we want our monitor to run the script
• TargetSystem: Enter the following $Target/Host/Property[Type=”Unix!Microsoft.Unix.Computer”]/NetworkName$. This is a variable that will be replaced automatically with the name of the Unix server at the time the monitor is run.
• Command: This is the absolute path of my PERL script as well as the absolute path of the directory I want to check as a parameter (ie. /tmp/fileCount.pl /tmp)
• ObjectName: This is an arbitrary title you can give for an Object Name.
• CounterName: This is an arbitrary title you can give for a Counter Name
• InstanceName: This is an arbitrary title you can give for an Instance Name.
• Value: This is where we define where to look for our results. In this case STDERR so enter $Data///”[local-name()=”StdErr”]$
• Threshold: This is the threshold value we are looking for. In this case, the maximum amount of files before we trigger a Critical health state.

7. On the Health tab configure the health states. Set UnderThreshold to be Health and OverThreshold to be critical.

8. On the Alerting tab check the option to Generate Alerts if needed and enter an appropriate subject line and description

9. On the options page change the Accessibility to Public.

That’s it for this one as well! You’ve just created a monitor that will run the script located at /tmp/fileCount.pl and based on the number returned from the script it will set the health state accordingly.

If you’re interested, click here for a zip file of the source code you can use to make things easier for you.

As you can see it is possible to leverage PERL scripts (or any other scripts) on your Unix/Linux hosts to monitor almost anything you can think of and show those results in OpsMgr. For more information about creating custom classes, views, and a bunch of other useful MP items I’d highly recommend checking out the Cross Platform Authoring Guide as it contains a bunch of useful information for these as well as other scenarios.