Condividi tramite


Discovering Multiple Services of an Application

I got the question below related to my MP development training.  It seems like a common scenario that many people would be facing, so I thought I would answer it here.

My goal is to create an mp for a LOB application to monitor services running. The LOB app has 3 different components running on 3 different servers. All of them have a common registry key installed on all servers indicating the app exists. However, each of them have different services running depending on the role. Regarding my discovery strategy, would it be best to start with a "seed" registry discovery for the application, then another registry discovery targeting the seed class looking for the service in the registry to identify what component of the app it is. I see all services for the app on all components listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services. Seems like I can do all my discoveries in the registry for this case. Would you say that if I can do all my discoveries in the registry then I should? Many thanks in advance!

This is pretty similar to the sample application that I use in the training.  I like using a seed class here because it gives us a quick and efficient way to identify which agents have any components of the application installed.  You can then target that class with discoveries for the services or any other component of the application. 

You probably want an abstract class to represent the application’s services and then a separate class for each service based on that abstract.  That gives you a target for common monitors that apply to all services but still allows you to uniquely monitor each one.  If the entire application is represented just by those services and you don’t see ever adding any other classes, then the seed class might be redundant.  I’m a believer in designing for the future though so I like using the seed which adds minimal complexity and overhead.

As far as which discovery methods you want to use, you’re correct that we always want to use the registry if we can.  It’s the most simple and efficient method of discovery.  That’s especially true when you’re targeting a broad class like Windows.Computer since you don’t want to put any additional overhead on agents where the application isn’t even installed.  You certainly can discover services from the CurrentlControlSet\Services key.  I tend to like WMI for that because you got back some information that isn’t in the registry, and it’s a little easier to read.  You may not use any of that additional information though, so the registry method may be just fine.  Of course, I would only use the WMI method against the seed because I don’t want to run unnecessary queries against all agents. 

Hopefully that answers the question.  Like programming, there is a degree of art and personal preference to management packs, so it’s often difficult to give a simple answer with only one option.  If there are more questions, please throw it out on a comment here.

Comments

  • Anonymous
    June 19, 2014
    I have created my seed discovery and discoveries for 3 different roles. I have also created state views that confirm that all roles are being discovered properly. My next step I believe is to move into the Health model. At this point the only thing I am interested in monitoring are the application services (which are a different service depending the role of the computer). At this point do I just need to create a service monitor (perhaps based on vbscript) targeting the custom class I created for each application role? IE: In the example of your video series targeting "MPAuthor.Stores.ComputerRole.CentralProcessor"? Keep in mind my goal is still the same as I mentioned before which is to simply create an mp for a LOB application to monitor services running.
  • Anonymous
    June 30, 2014
    Sounds like you just need some service monitors targeted at your custom classes. Probably don't need any vbscript.