Table of Contents
Aggregate Monitors
Aggregate monitors group multiple monitors to provide a single health aggregated health state. This provides an organization to all of the monitors targeted at a particular class and provides a consolidated health state for specific categories of
operation.
Standard Aggregate Monitors
Every class has four standard aggregate monitors: Availability, Configuration, Performance, and Security. These are in the System.Health.Library management pack and targeted at the Entity class. Because all classes inherit from the Entity class, all classes inherit these standard monitors. The standard set of aggregate monitors will be sufficient for most classes.
Most monitors will fall into one of the four categories represented by the standard aggregate monitors. Because of this, custom aggregate monitors will typically use one of the standard aggregate monitors as their parent instead of being positioned alongside them directly under the entity health. Unit monitors and dependency monitors will similarly use either a custom aggregate monitor or one of the standard aggregate monitors as their parent.
Custom Aggregate Monitors
Management packs can include custom aggregate monitors specific to the requirements of classes in a particular application. These monitors may use another aggregate monitor for their parent or the top level Entity State similar to the standard aggregate monitors use. Custom aggregate monitors can be configured underneath another aggregate monitor or attached directly to the entity state.
For example, the Windows Server 2008 Operating System (Monitoring) management pack includes an aggregate monitor called Microsoft.Windows.Server.2008.OperatingSystem.CoreServicesRollup that is used to combine the health of the different services that are monitored by this management pack. There are nine services that the management pack considers critical to the operation of a computer running Windows Server 2008. Instead of positioning these directly under the Availability aggregate monitor alongside other unit monitors, the aggregate monitor provides a combined health measurement for all the related services.
This aggregate monitor is illustrated in the following diagram.
Health Rollup Policy
Each aggregate monitor must define a health rollup policy which is the logic that is used to determine the health of the aggregate monitor based on the health of the monitors under it. The possible health rollup policies for an aggregate monitor are as follows:
Health Rollup Policy
ing">Worst state
The state of the aggregate monitor matches the state of the child monitor with the worst health state. This is the most common policy used by aggregate monitors.
Best state
The state of the aggregate monitor matches the state of the child monitor with the best health state.
Dependency Monitors
Dependency monitors let the health of one object be affected by the health of another object. This allows for health rollup between specific related instances of different classes.
Each dependency monitor is based on a specific hosting or containment relationship. Just creating a relationship between two objects does not alone provide rollup between their health states. A dependency monitor must be associated with the relationship for rollup of health to be performed.
The source and target class for a dependency monitor are defined by the relationship that the monitor is based on. The monitor must additionally specify a specific unit monitor or aggregate monitor on the target class and an aggregate monitor on the source
class. Only the health of the target monitor is considered when calculating the health of the dependency monitor, and it only affects the health of the specified aggregate monitor on the target object.
Dependency monitor based on unit monitor
Dependency monitor based on aggregate monitor
Multiple dependency monitors can be created on a single relationship if the health of the source class should be affected by multiple unit or aggregate monitors on the target class. For example, a dependency monitor might be created for each standard aggregate monitor as shown in the following image.
Multiple dependency monitors for a single class
Health Rollup Policy
There may be multiple instances of the target class, each with a different health state. Each dependency monitor must define a health rollup policy to define the logic that is used to determine the health of the dependency monitor based on the health of the instances of its target monitor. The possible health rollup policies for a dependency monitor are as follows:
Worst state policy
The source object matches the state of the target object that has the worst health state. This is used when the source object should only be healthy if all the target objects are healthy. This is the most common policy used by dependency monitors.
Best state policy
The source object matches the state of the target object that has the best health state. This policy is used when only one of the source objects has to be healthy for the target object to be healthy.
For example, the Microsoft Windows Hyper-V 2008 Monitoring management pack has a dependency monitor on the hosting relationship from Microsoft.Windows.HyperV.ServerRole to Microsoft.Windows.HyperV.VirtualNetwork that uses a best state policy. This is because the Hyper-V server is functional as long as it has one functional virtual network. The logic defined by this management pack is that the server class should show an error state if no virtual networks are available.
Best state health policy
Percentage Policy
The source object matches the worst state of a single member of a specified percentage of target objects in the best state. This policy is used when a certain percentage of target objects must be healthy for the target object to be considered healthy.
For example an application might run on a web farm that includes multiple Web servers. Because of the redundancy offered in this kind of deployment, the application might be considered healthy if a particular percentage of servers is available. The farm itself could be represented in the management pack by a health rollup class based on System.ApplicationComponent with a containment relationship to the Web servers. A dependency monitor could be created on this containment relationship with a health rollup policy specifying a percentage. Even if one or more Web servers had a problem, as long as the specified percentage were in a healthy state then the class representing the web farm would also be healthy.
Percentage Health Policy
Health Rollup between Agents
Health state can only be rolled up between objects managed by the same agent unless the source object is managed by the Root Management Server. Groups and classes used for health rollup are typically unhosted. This means that they are managed by the RMS so that they can roll up health from objects managed by different agents. A relationship can be discovered between objects managed by different agents, but any dependency monitor associated with that relationship will not work as expected.
Health rollup between agents
Health rollup between agents