Understanding Monitors in OpsMgr 2007 part III – Dependency Monitors

This is part 3 (and last) of my series of posts describing monitors.  The first post, found here, discussed unit monitors, which are the engine of monitoring. The second post, found here, discussed aggregate monitors, the ‘umbrella’ monitor sitting above unit monitors and reflecting their collective health forward – ultimately all the way to the class level. 

The dependency monitor is used to link classes that are in a hosting or containment relationship together, allowing health state from one class to affect the health of another class higher in the relationship structure than itself.  This type of monitor is confusing for many an OpsMgr admin.  Looking at the relationship structure of classes within OpsMgr one might think that the rollup of class health happens by default – it doesn’t.  Health will only roll up to the individual class level (by using unit and aggregate monitors) unless a dependency monitor is configured between classes.  An illustration from the Opsmgr Authoring Guide might help and is shown below.  In this scenario we have two objects, the SQL Server 2005 object (SQL Server 2005 DB Engine class) and the SQL Server Database object (SQL 2005 DB Class).  Using the unit and aggregate monitors, both objects can be monitored individually – but there is nothing that will allow problems with a database (SQL Server 2005 DB class) to reflect on the SQL Server 2005 object itself (SQL Server 2005 DB Engine). If we do need the ability to link health between the objects, the dependency monitor is the mechanism to do so.

The diagram shows a dependency monitor created that links the health state between the availability aggregate of the SQL Server Database object (SQL 2005 DB object) and rolls it up under the availability aggregate of the SQL Server 2005 database object (SQL 2005 DB Engine class).  You could link between the other aggregate categories or on the aggregate for the class itself, it’s up to you.

So how do we build this in the OpsMgr UI?  Let’s walk through it.

First, find the two classes you want to link together and evaluate what monitors are already in place. In this case, SQL 2005 DB and SQL 2005 DB Engine

We see that there is a Database Status unit monitor already configured and it will rollup it’s health to the availability aggregate and ultimately the entity aggregate but there is no dependency to roll the state up further.  Knowing that this view in the UI isn’t always as complete as we would like (more on that in a minute) and knowing that dependencies are created at the parent class in the relationship, in this case SQL 2005 DB Engine, we take a look at the SQL 2005 DB Engine objects in discovered inventory and look at health explorer for these objects and confirm there is no dependency.

Note:  Here we are specifically looking at the availability aggregate since the unit monitor we want to ‘link’ into is underneath this aggregate in our target class.

 
      Note: Here I’m looking at health explorer for my test computer object but it really
doesn’t make a difference which object you choose out of discovered inventory since
the rollup, when created, will be at the class level and will be displayed on all objects as
a result.

From this we know that there is no dependency, so we will build one.  Back in authoring we select to create a dependency monitor.

     Note: You could also create the dependency monitor (or any other monitor) directly on
the node of interested which will fill in some of the information for you in the wizard.

As shown above, the target for the monitor will be the class where we want health to ROLL UP and not the class that is reporting the health.  In this case, SQL 2005 DB Engine will be our target.

The next page is where we link our classes

In the above screen we are configuring our dependency monitor to link into the SQL Database child object and consider the health state of this child object when calculating health of the hosting class.  Notice that in this window we are actually linking to the more generic SQL Database object (the only option) rather than to the specific SQL 2005 Database object. 

OK, wait a minute – this is confusing.  So we want to create a dependency to link the health that results from the ‘database status’ unit monitor that is specifically created to monitor objects in the SQL 2005 DB class – but our dependency can’t link directly to the SQL 2005 DB class but, instead, has to link to the SQL DB class?  Come on Steve – I look directly at the SQL DB class, the one we can link to, and it doesn’t have ANY monitors defined on it.  You also said earlier that without a dependency monitor health rolls up to the top of the CLASS and stops.  In this example that means health would not go past the SQL 2005 DB class so how can I get ANY health rollup by building a dependency to the SQL DB class which has no monitors?  Yes, I understand the confusion but, trust me, it works.  All of what I mentioned earlier is true.  Health doesn’t roll up from class to class unless there is a dependency.  You might call me a liar if you were to cause the database status monitor to go red and then look at the SQL 2005 DB class and the SQL DB class in health explorer.  The screenshots below seem to contradict what I’m saying because when the Database Status monitor is healthy, both classes are healthy and when the Database Status monitor is unhealthy, both classes are unhealthy.

SQL 2005 DB Class                                   SQL Database Class

While my statement that health will NOT rollup past the individual class level without a dependency is true it is also true that in some cases health generated on one class will reflect, not rollup, on it’s parent class.  The reason for this is a bit complicated to explain but a good way to predict when this will be the case is where one class specializes another class but what is ultimately being described is the same.  In this case, the SQL 2005 DB class is a more specialized for of the SQL DB class so the type of special relationship we are talking about exists.  OK, lets continue building our dependency monitor!

On the next screen we simply configure how health should be considered.

So what impact did this change have?  Take a look back at our two classes and we will now see the dependency monitor.  While the UI doesn’t clearly reflect it we now know based on our configuration and earlier discussion that the new dependency monitor will evaluate the health state of the availability aggregate from our child class when evaluating health.

So with the dependency monitor in place here is how health rollup really happens.  The health state changes on our unit monitor, rolling up to the availability agregate in the SQL 2005 DB class.  Because or our ‘special’ situation with these classes, health from SQL 2005 DB availability aggregate will reflect on the availability aggregate of the SQL Database class.  Our dependency monitor, created on the SQL 2005 DB engine availability aggregate, will ‘link’ into the availability aggregate defined on the SQL Database class and ‘roll up’ health according to the rules defined on the dependency.

For another view of this rollup taking place we look at health explorer for the SQL 2005 DB Engine class.  Health explorer is generally the clearest way to see these rollups and make sense of them.

Earlier I mentioned that using the authoring section of the UI to try and follow a dependency monitor and understand the classes it links together is potentially problematic.  This is illustrated by the above diagrams.  The dependency is created at the SQL 2005 DB engine level – and the dependency is visible at this level.  But looking at the class the dependency links to alone doesn’t give any ability to know that a dependency is actually in operation.  Health explorer is the right way to visualize the total picture of the health structure.  It still may be difficult to see at a glance which monitors are aggregates or dependencies but by working with the structure a bit, it isn’t that difficult to follow.

Comments

• Anonymous
  July 16, 2013
  Hi, What should I do when I get "Non-healthy state of availability is rolled up. Child health state was rolled up to traget class instance." ? ham_zar@yahoo.com Thanks, Hamid