One of the most frequent requests we get from customers is to create monitor for application services. Often enough you will find management packs for well know applications, but if you can’t, you will need to create those by yourself. With that, you have basically two options: use the provided Authoring Template in the SCOM console, which has been extensively described on the internet or create monitors in the same authoring area of SCOM, but using an existing target, like Windows Operating system or Windows Computer.
The first option is good because SCOM will not only monitor the services, but it will also create a discovery for those services and make them available to be listed as independent objects in a State view, for example. The cons of this approach is that if you have a lot of services, a lot of work will be required to create all the monitors. It also uses a lot more resources to discover the services, since for each monitored service, you a discovery will be added. This template is also good if you want CPU and and memory monitoring for the services, which are available through the template as well.
With the second option, which much leaner in terms o resources, the con is that the services themselves do not become objects themselves. The monitors for each one of them will be visible in the Health Explorer only. Alerts will work normally though.
What should you do then?
Well, there is a third option, which will require some XML edition and authoring skills. I’ve been using this for different customers and it has a good feedback. To build this solution, I’m using Visual Studio 2015 with the Management Pack Authoring extensions.
It all starts with a Class definition:
<ClassType ID=”Company.Application.Class.Computer” Accessibility=”Public” Abstract=”false” Base=”Windows!Microsoft.Windows.ComputerRole” Hosted=”true” Singleton=”false” />
This one defines a computer class that will host the services. And now the services themselves:
<ClassType ID=”Company.Application.Class.Service” Accessibility=”Public” Abstract=”false” Base=”Windows!Microsoft.Windows.LocalApplication” Hosted=”true” Singleton=”false”>
<Property ID=”ServiceName” Type=”string” Key=”false” CaseSensitive=”false” MaxLength=”256″ MinLength=”0″ />
<Property ID=”ServiceDisplayName” Type=”string” Key=”true” CaseSensitive=”false” MaxLength=”256″ MinLength=”0″ />
<Property ID=”ServiceProcessName” Type=”string” Key=”false” CaseSensitive=”false” MaxLength=”256″ MinLength=”0″ />
<Property ID=”StartMode” Type=”string” Key=”false” CaseSensitive=”false” MaxLength=”256″ MinLength=”0″ />
<Property ID=”LogOnAs” Type=”string” Key=”false” CaseSensitive=”false” MaxLength=”256″ MinLength=”0″ />
Next, I will need two discoveries, one to discover the computers and then, another one to discover the services. This could be condensed in a single script discovery, but WMI is less expensive than scripts in terms or CPU cycles.
First the computer discovery:
Make sure you pick the right service prefix in the WMI query part, to properly identify the computers that belong to that class.
This discovery will then scan all computers that are part of the Windows Server Operating System Class every 15 minutes. Once one machine with that services mentioned above is found, a new instance of the Company.Application.Class.Computer class will be created.
And the service discovery itself:
This discovery will scan all the previously discovered computers that belong to the Company.Application.Class.Computer class and look for the services according to the WMI query. Once any of the services is found, a new member of the Company.Application.Class.Service is discovered and the properties are mapped:
Having Service objects as entities by themselves makes it easy to monitor, since you can only create a single monitor that targets all the objects:
And that is pretty much it. The remaining pieces of the MP references, presentation and display strings. Make sure to customize the IDs and messages according to your needs.
The final MP can be found here.
Hope this helps!