OpsMgr R2 Authoring Console – Business Hours monitor


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:

  1. Create a new MP using the Registry App from the Authoring Console. This will create for us a new class and an appropriate discovery
  2. Create a composite monitor type. This is the trickiest part.
  3. Create a monitor based on the previous type.

So first step, in the AC let’s create our new MP:

image

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.

image

Finally let’s add the proper filter

image

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.

image

image

1) create a new composite monitor type and give it a name

image

2) define the monitor states, just 2 in our example

image

image

3) Add and configure the performance data source

image

image

image

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.

image

image

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>.

 image

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.

image

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.

image 

image

8) Define the regular detections for both the monitor states

image

9) eventually define the unit monitor in the health model

image

10) define the monitor type

image

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.

Technorati Tags: ,
About these ads
  1. #1 by Raymond on December 10, 2013 - 9:46 pm

    Daniele,
    Thanks for all the hard work . I used the business hrs composition extensively in both Linux and windows. Is it possible to create a standard module type that changes resolution state from warning to critical based on the amount of time a service/process is in a specific state ? IE after 10 minutes a downed service monitor issues a warning alert. after 15 minutes a critical alert is issued for the same service ?

    • #2 by Daniele Grandini on December 13, 2013 - 6:12 pm

      Hi Raymond,
      this is an interesting challange, for sure we can make the workflow stateful adding a POSH script, but I’m wondering if we can reach the same result using a sliding window correlator. I never tackled such a task, but it’s Worth a try. Alas in this end of the year period I’m fully booked, maybe I can give it a try during the holydays. Not promising anything :-).

      - Daniele

      • #3 by Raymond on December 17, 2013 - 6:49 pm

        Daniele,

        Thanks for the quick response . Enjoy the holidays ! … I am always grateful for whatever you have done for me and the community . Is there documentation online on how to do this with POSH ?

        Buon Natalie !

        Raymond

    • #4 by Daniele Grandini on January 17, 2014 - 3:53 pm

      Hi Raymond, I didn’t forget this topic. Thinking ont eh topic we basically have two ways to achieve the result, in the first one you just have to rewrite the datasource for service state using some Scripting (POSH or WScript). In the script just check for service state and if it’s bad write a registry key with the time stamp. Subsequent run must check the service state and if it’s bad compute the elapsed from the registry timestamp, if it’s good just reset the registry time stamp. To get a unique registry path you should use GetScriptStateKeyPath(). There’s a second way that theoretically should work, it involves correlators (see http://msdn.microsoft.com/en-us/library/jj130281.aspx).

      Daniele

  2. #5 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.

    • #6 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

  1. 2010 in review « Quae Nocent Docent
  2. Cameron Fuller

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 266 other followers

%d bloggers like this: