The new authoring console that will be available with R2 has pros and cons (see my previous post) but for sure can be used to simplify the creation of basic monitors that must be run during business hours.
The process is not intuitive, you must know how to build such a monitor, but nevertheless can be of great help when XML is seen as too awkward.
I want to follow up to my previous posts on running a specific monitor during business hours showing how to achieve this via the Authoring Console. So, let’s take into account the scenario in which I want to monitor a LOB app CPU utilization only during business hours.
A word of warning the MP we’re going to build is far from being complete, for example our monitor will not allow overrides nor we’re going to implement OnDemandDetections. Based on feedback and time I can build on that in future posts, but I’m not promising anything.
From 1,000 feet this what need to accomplished:
- Create a new MP using the Registry App from the Authoring Console. This will create for us a new class and an appropriate discovery
- Create a composite monitor type. This is the trickiest part.
- Create a monitor based on the previous type.
So first step, in the AC let’s create our new MP:
Now remember to:
- change the default discovery interval to at least 1 hour (the default is just crazy, 15 sec). As a best practice consider using at least a 4 hours interval in discoveries.
- define an appropriate registry path to discover the app, in my example I will just test for a registry key existence for my mock application TestApp.
Finally let’s add the proper filter
Now your MP is able to discover the LOB application based on registry key existence. You can import it and check if the application is being discovered, the easiest way to do this is to use the Discovered Inventory view in the monitoring workspace of the Ops Console.
Now comes the trickiest part, to build a monitor that runs only during a specific time window we must build a composite monitor with a workflow like this: a scheduler (our time window) –> an action probe –> at least one condition detection for every status we want (2 or 3 actually. Strictly speaking we can have a state for the undetected condition, but this will just add complexity to our example). Since we’re using a perf counter we have to slightly change our workflow, in fact we do not have probe performance providers, just data sources. One of the way to overcome this is to change the composition like this: performance data source –> scheduler filter condition detection (our time window) –> at least one condition detection for every status we want.
So let’s go to work.
1) create a new composite monitor type and give it a name
2) define the monitor states, just 2 in our example
3) Add and configure the performance data source
4) Ad two condition detections one for each monitor state. Since the monitor is based on performance it’s a good idea to use an Average Condition over a given number of samples. Let’s say our TestApp is ok if it uses less than 20% CPU time.
5) Add the Scheduler Filter this is where we’re going to define our time window or business hours. Here we must overcome a limitation in the current build of the Authoring Console. Since we’re talking about business hours is highly probable we need to consider the server local time, to do this we need to change the TimeXPathQuery property (useless in our scenario) with UseCurrentTime. We cannot do it directly form the authoring console so we must hit the “edit” button and change the resulting xml from <TimeXPathQuery>TimeXPathQuery</TimeXPathQuery> to <UseCurrentTime>true</UseCurrentTime>.
6) Use the configure feature to define via the UI the business hour period, in this example every day from 7:00 AM to 8:00 PM.
7) Now we have all the modules that we need to build our monitor type. The pictures shows all the modules you must have at this time. We just miss the workflow.
8) Define the regular detections for both the monitor states
9) eventually define the unit monitor in the health model
10) define the monitor type
11) associate the monitor type states to the monitor state and that’s it
– Daniele
This posting is provided "AS IS" with no warranties, and confers no rights.
#1 by curtiss on September 13, 2012 - 11:41 pm
i configured my scheduler module exactly like yours, but i can’t get it to pass the performance data collected in the data source module to the condition detection module after the scheduler module. no data gets passed. it stops at the scheduler module. (i’m viewing this in the auth console simulator). if i remove the scheduler module and go straight from the data source to the next condition detection, it works fine.
#2 by Daniele Grandini on September 14, 2012 - 4:00 pm
The composition should be DS – Scheduler – CD. When you test it in the Authoring console is the scheduler condition satisfied? If you configured the monitor type as described you can be sure it will work.
-Daniele