Based on the feedback I received I go on with this sequence of posts about monitoring during business hours. As we’ll see implementing this kind of monitor for a service it’s quite cumbersome, so once again my advice, remember in many cases you can live without this feature:
- you can specify business hours in reporting
- you can suppress rule based alerts raised during non BH
- you can schedule maintenance for the object, even if there’s some drawback with it (see my future post “The nasty side of maintenance mode”)
- you can avoid receiving alerts message tuning your subscriptions
Having said that, let’s go to work.
Creating a service monitor from UI creates a simple discovery rule for the named service; the discovered object class is Microsoft.SystemCenter.OwnProcessNTService. This class inherits several monitors and rules, just to name a few:
All these monitros are based on the following Monitor Types:
These types are in turn based on the following data sources:
- Microsoft.SystemCenter.NTService.FilteredWin32ServiceInformationProvider this one in turns is based on the Microsoft.Windows.Win32ServiceInformationProvider
So what we have here is a chain that leads to the Win32ServiceInformationProvider, what we need to do is rewrite the monitors (yes, we need to disable the standard ones and create our owns) so that the DataSource is invoked just during BH. But here we have a few problems:
- The Win32ServiceInformationProvider just accept a frequency in its config manifest and it’s native. This mean we don’t have a composition we can filter with a scheduler
- DataSources are supposed to be the first module in a composition (see http://www.authormps.com/dnn/Concepts/WorkflowBasics/ModuleTypes/tabid/115/Default.aspx) since they do not have any input stream and probably we do not want the monitor to run altogether during non BH
Digging into the Microsoft.SystemCenter.NTService.Library MP we can find we have a companion probe Microsoft.Windows.Win32ServiceInformationProbe. This is what we need, this way we can build a composite module combining: scheduler -> scheduler filter -> probe.
By now we have all the components required to build the new monitor types, for example sake let’s concentrate on the CheckNTServiceStateMonitorType. The original one has the following composition: Win32ServiceInformationProvider every 60 seconds. We will change it to have the following: System.Scheduler -> System.SchedulerFilter -> Windows.Win32ServiceInformationProbe.
Obviously I could have had a different approach: let’s run the check but filter out the result during non BH. In this case my composition would have been Win32ServiceInformationProvider -> System.SchedulerFilter.
I attach a simple MP in which I add the monitor to a specific UI generated service monitor. In the MP you can find both strategies: Progel.NTService.ServiceStateMonitor1 uses the first approach using a scheduler and the a filter, Progel.NTService.ServiceStateMonitor2 just filters out result from the DS. The main difference between the two is the second one always run the service check and just filters out the resulting stream, the first one runs the service check only during BH. Since both modules are native it’s difficult to say which is the best approach on a performance point of view. Imo the first approach makes more sense on this respect.
Please use it just as an example it lacks some polishing (read configurable parameters, display strings, etc.)
Now the question is: is it worth?