A Powershell Monitor for ‘Leaky Processes’ (Part II – DataSource Design)

So now we have a script that we can put into either an existing management pack or a new management pack and have it drive a new type of monitor.  For this example I will walk through putting this into a standalone management pack.

Step 1:  Open Authoring Console –> File –> New Management Pack

Step 2:  Give the Management Pack a unique and meaningful name

image

image

Step 3:  Create the New Composite Data Source.  Type Library –> Module Types –> Data Sources

image

Step 4:  Give our new DataSource a unique meaningful name.

image

Step 5:  Give the new DataSource a Display Name.

image

Step 6:  Setup the Member Modules

Member Modules are the subcomponents of the DataSource.  In our case we will need something to schedule the execution of our script, and something to execute and return values from our script.

System.Scheduler is the generic scheduler and will allow you execute any DataSource on a Schedule

Microsoft.Windows.PowerShellPropertyBagProbe is Built-in for running PowerShell scripts that return non-discovery data

image

 image

image

image

image

image

image

image

image

image

Step 7:  Setup the Configuration Schema of this DataSource

The Configuration Schema is simply a list of things that this DataSource needs defined for it inorder to run correctly.  This includes all of the $Config/Parameter$ variables we declared previously (it needs to get the data from somewhere and this say that it can expect to have it passed to it from whatever ends up calling it)

image

image

image

image

image

image

image

Next Steps:  Create the new Monitor Type for this DataSource (where we define what it means to be healthy or unhealthy) and then use that monitor type in an actual monitor!  Stay Tuned!

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

2 Responses to A Powershell Monitor for ‘Leaky Processes’ (Part II – DataSource Design)

  1. Jonathan Almquist says:

    Keep in mind that if you plan to use cookdown, those overridable configuration elements will break cookdown if user actually creates an override or if this DS is to be used for more than one monitor and different elements are passed in. The one thing to bear in mind when creating a DS that is expected to use cookdown, and that is all configuration elements must be the same up until after the DS. Anything after the DS we can change without breaking cookdown functionality.

    • randorfer says:

      There is no need for cookdown with this module as it is only executing against a single instance class (we are not firing this against every process although it does end up providing information on all of them)

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