Using MPAuthor to create a class, discover and monitor a service


 

This post will be a simple walk through on how to create a class for an application, discover instances of that class, and then monitor a service associated with that application:

First – make sure you have the latest version of MP Author from Silect:  http://www.silect.com/content/mp-author-free-download-form

Open up MP author, and create a new Management Pack.  If you are prompted about reference packs – choose Yes.

Provide a name for your MP.  In this example – I am going to discover and monitor anyone running the Microsoft iSCSI Initiator service. 

image

I create a folder structure for all my custom MP’s in C:\MPDEV:

image

Accept default references and then choose empty management pack:

image

Then Finish.

 

Create the Target Class

 

 

Browse to Targets, right click – and choose New Registry Target:   (hint: A Target is the same thing as a Class)

image

Browse to a machine on your network running the service you seek:

In this case – I am going to browse the HKLM\SYSTEM\CurrentControlSet\Services hives, looking for the iSCSI initiator service, which is MSiSCSI.

Now if I just wanted to discover all the systems that had this registry path – I could.  But that is not really what I am after.  I want all systems that are actually RUNNING the service.  So I will trigger on the registry VALUE of “Start”.

2 = Automatic.  3 = Manual.  4 = Disabled.

I highlight the Registry value I want (Start) and click Add:

image

Click OK and I have this:  I want to discover when the service is set to Automatic (2)

image

Now I need to give my Application a name.  I could accept the defaults here but I like to customize this:

image

Next – we can customize the details for the discover.  I like these so I leave them at their defaults:

image

Next on the Expression – I can ensure that I am checking for a specific content of a registry value, or just look for the existence of a registry key or value.

image

For the frequency – every 1 days is almost always sufficient.  The agents will run this discovery immediately once they receive the MP so you wont need to wait a full day while testing.  Also – agents run these discoveries on every agent startup – so for testing we can bounce the agents if we need it to run again.

image

At this point we can save our work – and test import this into our lab.  Right click the management pack itself, and choose Deploy:

image

Input your SCOM server and your credentials, and MP Author will do the rest.  You will see this when it finishes:

image

 

Now – lets check and see if we are discovering the right instances:   In the SCOM Console > Monitoring > Discovered Inventory.  Change target type to your new class. 

image

 

I can see right away that I am discovering instances!

image

 

These are showing as “Not Monitored” and this is by design.  We have not targeted ANY monitors to this class yet, therefore there will be no state to roll up.

Lets go do that now!   Back in MPAuthor, lets increment our MP version:

image

 

Create a Service Monitor

 

Then go to Monitors, right click, and Create New Service Monitor:

image

Browse the same server as before, and find your service in the list.  NOTE***  We need to change the “target” class from the default of Windows Computer, to our custom class we created as seen below:

image

 

Customize the name of the monitor to make good sense:

image

Specify your desired health states:

image

 

Configure and customize alerting:

image

 

Creating Folders and Views

 

While we are here – we should create some folders and views for our MP to round it out:

We need a folder for the MP to show up in the monitoring view:  Allways choose Microsoft.SystemCenter.Monitoring.ViewFolder.Root

image

Then customize the name/display/description

image

Once that is complete – create a view:  Lets start with an Alert View:

image

For the folder – choose the folder we just created, and Alert category:

image

Set the target for the view – this will be the scope of the alerts we want to see, so I restrict this to our custom class. 

image

Then customize the view ID/DisplayName/Description:

image

 

Now lets create a state view for viewing the health state of our new class:

image

I want an unfiltered view – so I configure it to show me all states of my custom target class:

image

image

 

Save that, and Deploy it!

 

Now I can see my Folder, and my views.  I have health state working:

image

And my alert views and alerts are working:

image

 

 

Summary:

 

As you can see – this is creating management packs the RIGHT way.  We don’t have to target everything to “Windows Computer” and try to work woth overrides and enable for this, disable for that, and make a big mess.  We should create classes for applications and monitor each application/service as an entity.

We created a class, created a monitor, and created the folder and some initial views.  Adding additional monitoring to this just gets easier and easier.


Comments (11)

  1. Jesty says:

    Thanks for the blog Kevin.. we would include the same in our best practices for authoring rules and monitors for a class.

  2. Sascha Bieler says:

    Thank you so much for this excellent blog post. Made things easier, again!

  3. Ricci says:

    I glad to see post talking about right way create target for monitoring, but still little disappointed to see tutorial written with 3rd party tool. You can show how do things using authoring extensions?

  4. Prakash Bhimji says:

    Great Article Kevin, our current environment is a total mess, every monitor is targeted to "Windows Computer"

  5. Matu says:

    It is one of the best tech blog!
    Please do not stop writing! 🙂
    I'm looking forward for next topics!

    Thanks a lot for sharing your knowledge.

    Best regards.

  6. Srinivas Kanugula says:

    It is really excellent for Beginners for understanding the Management Pack

    Thanks,
    Srini

  7. Brian says:

    Everything worked out well until I got to the part of the State View creation. Once I deployed the finished MP into my management group it never pulled in the servers into that State View. I could see them under Discovered Inventory and the class that
    I created. When creating that health state I pulled in the new class. Is there some other step that I missed?

    -Brian

  8. Joe says:

    Hi Brian,

    I noticed the same thing and think I found a bug. If you view the XML of the state view you will see the Severity section. When healthy is selected it actually puts unknown. You need to change the XML from "Unknown" to "Green". Once I did this my machines started
    to show up.

    Joe

  9. Floris says:

    Hi Kevin, great blog!
    I Was wondering if it would be possible to use several targets vs monitors in 1 MP.
    My purpose is to connect certain targets to certain services. If service has reg key a/b/c then monitor services a/b/c | if a server has reg key a/d then monitor server a/d
    Is something like this possible?

  10. @Floris - I'm not sure in what context you are using service. It sounds like the first item is "business service". Thereafter, windows services? This is doable but there are possible challenges:

    1. Create a class for your business service. Discover this business service based on a generic service registry key e.g. HKEY_LOCAL_MACHINESOFTWARESCOMDiscoveryDataMyApp

    2a. Create a class discovery monitor for each windows service that could exist with health roll ups configured to class in step 1 (or use localapplication for an automatic health roll up). Where the windows service is discovered, the monitor will execute.
    Where the service is not discovered, the monitor will not execute. However, this requires a class per windows service which might be unnecessary overhead unless you need a class per windows service e.g. for setting individual maintenance mode on the specific
    windows service.

    2b. Create a script based monitor targeted at the business service - check for windows services installed and their status. This is more overhead on the monitored server than a unit service monitor.

    The challenge is that you can only target monitors at a class (and not based upon the properties of a class). I'd tend towards option 2a if I had to choose between them.

    You could also look to leverage the fact that there is a “Alert only if service startup type is automatic” switch which means that in step 2a, you could target service monitors for each service at the Business Class and only services which exist on the server
    and are set to automatic start are actually monitored. I'm not a fan of that approach for reasons discussed here -

    http://blogs.technet.com/b/kevinholman/archive/2010/11/07/monitoring-windows-services-automatic-manual-and-disabled-using-checkstartuptype.aspx

  11. @Ricci

    I'm starting up an authoring series across on the Microsoft UK SCOM PFE blog -
    http://blogs.technet.com/b/manageabilityguys/archive/2015/08/24/visual-studio-management-pack-authoring-series-overview.aspx - which might help.

    I actually find Visual Studio very quick for authoring by creating a fragment library that covers most monitoring scenarios. It is even possible to use snippets to facilitate rapid creation of code that can be used as a basis for more extended monitoring.
    http://blogs.technet.com/b/manageabilityguys/archive/2015/08/14/dasnippet.aspx

Skip to main content