A PowerShell Monitor for ‘Leaky Processes’ (Part IV Implementing the Monitor)

Now that we have created the Custom Composite monitor using it is just like using any other type of monitor.  So, generically when implementing a monitor you have two choices:

  1.   Put it on a pre-existing class (default disabled, enable for the servers you want to monitor)
  2.   Attach it to a new class.  Use discovery to control where this is monitored.

As this module is PowerShell based we cannot run it on all of our servers as not every server has PowerShell installed.  Rather what I plan to do is create a ‘LocalApplication’ class for the ComputerRole.  I will call this class PowerShell and use it is the target for all my powershell based monitors and rules.  I will use the registry key for PowerShell as the determining factor for installed or not and discover its version as a property (this may allow me more functionality in the future if I ever utilize functionality exposed in 2.0 that is not exposed in 1.0).  So, lets go ahead and do that!

image

image

image

image

So now we have the class, we need to setup the discovery to tell when we should monitor this class.

image

image

image

Choose the Filtered Registry type for Configuration

image

Daily Discoveries are just fine for our environment

image

Use Regedit to find Key and Values that we are interested in and say “Copy Key Name”

image

We will the use the Key as our exists variable (if this key is present on a server we say that PowerShell is installed).  Paste the key name from your buffer into the Path area.  Make sure to remove the HKEY_LOCAL_MACHINE part as the SCOM module defaults to HKEY_LOCAL_MACHINE.

image

Note:  We chose Key for exists because we are just checking if the “Key” of the registry is there.  The only two valid Attribute Types for “Key” are Bool or Check if Exists (which is the same thing as Bool).  This will return True if the registry key exists on a server and False if it does not.  The Name under properties is the name of the variable in SCOM not the name of the key.

image

The next thing I want is to discover what version of PowerShell this is.  Again, look at regedit and grab the key location, remove the HKEY_LOCAL_MACHINE prefix and add \NameOfValue

image

image

image

The next step is to setup the Expression for the discovery.  An expression for a discovery is a logical expression that must evaluate to True for the server to be ‘discovered.’  You base this logical expression on the information that you just gathered.  In our example we will be saying if Exists is True then this server has PowerShell.  Note you can access the variables you defined in the previous page with the …

 

image

image

The next step in the discovery is the Discovery Mapper.  This is where we tell the class what the Properties of the class we are discovering should be set to (usually we are populating this with data we just discovered!).  Note, all Values under “Key Properties” must be filled in.  You can access properties of the parent class (target class for the discovery).

image

The XPATH Query convention for accessing the variables we defined previously is $Data/Properties/VariableName$

image

So now we just say OK and the discovery is setup

image

image

So now we have a class defined, a discovery that will only discover the class when PowerShell is installed, and a Composite Monitor powered by a PowerShell script to monitor for processes that are leaking handles.  Lets put it all together and wrap this up!

Go to the Health Model –> Monitors Section and create a new custom performance monitor (could be any type but I would classify this as a performance monitor) under our new PowerShell Class.

image

image

The Next step is to setup the configuration of this Custom Monitor.  Browse for a type and select the CustomMonitor Type we created in Part III.

image

Now setup the defaults for your environment

image

Setup your health

image

Setup your Alerts.  In an alert the XPATH query to access a property bag value is

$Data/Context/Property[@Name=’VariableName’]$

Since we setup the property bag value ‘message’ in the script for displaying which processes have high handle counts I will include that in my alert description.

image

Set the Category to PerformanceHealth under options as this is a performance health monitor

image 

You could also add some Product Knowledge to this alert to let people know what it is all about / where to find more information about handle count leaks.  That is setup under the Product Knowledge Tab

image 

This will open up Word and you can add whatever knowledge / links you would like to it.  After that you are done!  You can now import the management pack into your testing environment and begin playing with it!  If you would like to download the .XML or .MP files that I created while making this demo it is available here

Advertisements
This entry was posted in Management Pack Authoring. Bookmark the permalink.

2 Responses to A PowerShell Monitor for ‘Leaky Processes’ (Part IV Implementing the Monitor)

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