A PowerShell Monitor for ‘Leaky Processes’ (Part III Monitor Type Design)

So now we are to the point where we can make a monitor type for our shiny new data source.  We can then use this in an actual monitor and start monitoring for this condition on servers!

Step 1:  Create New Composite Monitor Type

image

image

image

image 

Add in Member Modules.  What we want here is the DataSource we created in Step II and then two condition detections, one for our NoLeakingProcesses state and one for our LeakingProcesses state.

image

We want to setup our configuration of the ProcessHandleLeak DataSource to push off setting the specific values for our variables until we actually implement the monitor against a class.  So, to do this, we will again use configuration variables.  This time we will use the ‘promote’ option in the Authoring Console which will automatically create the variables in the configuration schema pane (we will still have to define the value type – int, string, etc – though).

image

image

Now we add in our condition detections.

image

image

image

image

The next thing we have to do it determine the “Regular Composition”.  This simply means for the State NoLeakingProcesses what does the flow through the monitor look like and what does it look like for the State LeakingProcesses?

image

image

image

The next step is to update the Configuration Schema.  Note this time we do not have to create the variables (because we used promote) but we still have to set their types.

image

The Final Step in creating the Composite Monitor is setting up the overrides.

image
You now have now created your own composite monitor powered by a custom, PowerShell driven DataSource! Stay Tuned for how to use this new Composite Monitor to actually monitor for Processes that are Leaking Handles as well as the .XML Management Pack!

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

2 Responses to A PowerShell Monitor for ‘Leaky Processes’ (Part III Monitor Type Design)

  1. Jonathan Almquist says:

    In your last post, you specified overridable configuration on the DS. If you do not plan to use the DS by a monitor directly, you only need to specify the overridable configuration elements on the monitor type. In other words, overridable configuration elements are only accessed directly, and with a monitor type, the DS doesn’t need them.

    • randorfer says:

      Johnathan,

      A lot of the work I end up doing is for a generic in house Library that we reference from other management packs. Putting overrides in both places is just habit. I am not always sure of every application for a DS or monitor type. You are correct though, for this example it is redundant, thanks for the catch

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