Introduction to System Center Operations Manager 2012 (Part 6) – Monitors

If you would like to be notified of when Scott Lowe releases the next part in this article series please sign up to our Real Time Article Update newsletter.

If you would like to read the other parts of this article series please go to:


Welcome back! So far in this series, you’ve learned how to get System Center 2012 Operations Manager installed and begin some basic monitoring activities.

Part 2. You performed a complete installation of the product and, by the end of the article, had a working system.

Part 3. You gained an understanding of the OpsMgr framework.

Part 4. You discovered how to manage agents, which are key to making OpsMgr operate.

Part 5. You will learn how to further manager OpsMgr 2012 by investigating rules and monitoring.

In this, part 6, you will continue to investigate the OpsMgr interface and discover how monitors work.

What are monitors

In the previous part of this series, you saw how the beginnings to how rules work. As a short recap, suppose that you have a disk that’s running at 8% free space. Let’s say that the management pack you’re using expects to see at least 15% available space, below which the management pack wants to raise an alert. It’s the job of a monitor to keep an eye on this very granular metric and report back to OpsMgr the current status.

You may recall that monitors are used to determine health information and make sure items are working within predefined specifications. If things are out of whack, monitors can raise an alert.

Monitors can be in any one of three states:

  • Green. All is well with the world. Go home and relax!
  • Yellow. A monitored element has fallen into a warning level for the particular monitor. For example, you might configure a free space alerts to go to yellow when a disk goes below 15% free space so that an administrator can be alerted that something might be amiss.
  • Red. Now, suppose that disk falls below 5% available space. In this state, the alert may show as red, indicating that immediate action on the part of the administrator is necessary.

There are a few different kinds of monitors available for your use. Each is described in the sections below.

Unit monitors

Unit monitors are often described as the “workhorses” of SCOM monitoring and are the most common kind of monitor out there. A unit monitor is used to measure a specific item, such as the amount of free disk space on drive C:.

In short, unit monitors measures some aspect of a service. This might consist of checking a Windows performance counter to determine the current performance of a specific service, running a script to perform a synthetic transaction that is then measured against predefined management pack rules, or watching for an event in an event that indicates an error that needs to be raised to the administrator.

The table below describes the various kinds of unit monitors you might encounter as you work with OpsMgr.

Unit monitor type

Data source


Event monitor

Windows Event logs

Looks for events in the Windows event log matching specified criteria.

Text logs

Tracks specific text-based logs.

WMI events

Monitors events created by Windows Management Instrumentation (WMI).

Syslog events

Looks for events from Unix systems and other devices that use Syslog.

SNMP events

Looks for matching criteria in traps sent from SNMP devices.

Performance monitor

Windows performance collection

Use a performance monitor counter as a rule in OpsMgr.

WMI performance

Collect a performance value from a WMI query.

Script monitors

Script collection

Monitor a value from a scheduled script.

Script monitors

Collect events or performance data from a scheduled script.

Table 1

These unit monitors can be used at an extremely granular level and provide you with a multitude of ways to monitor even the most minor elements of system stability, performance and health. They also form the basis for all of the monitoring that takes place in Operations Manager.

How does this monitoring work? Actually, monitors and rules – which we will discuss in a later part in this series – work hand in hand. Let’s go back to the disk space example. A monitor is created that uses Windows Management Instrumentation (WMI) to retrieve the currently available free disk space on C:. An associated rule is created that compares the returned value to expected values. When the returned result is below that predefined threshold – according to the rule – an alert is raised in the OpsMgr console telling the administrator that attention is necessary.

Aggregate rollup monitors

An aggregate rollup monitor is a collection of several other related monitors. State can be monitored on either a best-case or worst-case basis, depending on the nature of the service. The word related here is in italics for a reason. Aggregate monitors generally watch similar items – such as a group of DNS servers or a group of DHCP servers – and report back to OpsMgr on the overall health of the service group as a whole.

Here’s how an aggregate rollup monitor can be used: Suppose you’re using a dependency rollup monitor to watch eight separate DNS servers. You could create a high level monitor that undergoes a state change only once five of the eight DNS servers become unavailable. In this way (i.e. Only raise alert if 5 of 8 DNS servers are down) you can be alerted on your terms. However, in order to truly understand how aggregate rollup monitors work, you need to understand a bit about health rollup policies.

Health rollup policy

When you have a group of items being monitored with an aggregate monitor, you have two choices for how you want the state for the monitored group to be reflected.

Worst state health policy

The most common policy used by aggregate rollup monitors is called the Worst state health policy. In this instance, the aggregate monitor matches the state of the child monitor that has the worst health state in the group. So, if you’re monitoring 150 items with an aggregate monitor and one of those 150 items goes into a failure state, the entire parent monitor is shown as being in a failed state. The worst state aggregate monitor is demonstrated in the left picture in Figure XX below.

Best state health policy

On the opposite side of the health spectrum lies the best state health policy, which is the opposite of the worst state. In this scenario, the parent rollup monitor is assigned the status of the healthiest member of the monitored group. In Figure 1, this is demonstrated on the right-hand size of the diagram.

Worst state health policy

Figure 1: Aggregate monitor health rollup examples

Dependency monitors

Also known as a dependency rollup monitor, a dependency monitor in SCOM 2012 allows the health of one object to directly affect the health of another completely unrelated object. Although dependency monitors are similar to aggregate rollup monitors, they are more flexible and much more granular. In Figure 2 below, you can see how this might work. Suppose that the “different monitored item” is the aforementioned free space on drive C:. The “monitored item” might be a Windows server object whose health is dependent on a number of underlying dependent monitors.

Figure 2

This type of monitor also adheres to the previously discussed best and worst health state policies. However, there is some additional flexibility with this kind of monitor. You also have the capability to define a percentage health policy. Suppose you have five monitored items and a percentage health policy of 60%. This would mean that 60% of the monitored items would need to stay operational before the monitor goes red. In this example, the monitor would stay green even if two monitored elements failed. But, once a third one failed, the 60% availability threshold would be violated and the monitor would go red.


This has been a primer for how monitors work in OpsMgr 2012. We will continue our introduction to OpsMgr 2012 in Part 7 of this series.

If you would like to be notified of when Scott Lowe releases the next part in this article series please sign up to our Real Time Article Update newsletter.

If you would like to read the other parts of this article series please go to:

About The Author

1 thought on “Introduction to System Center Operations Manager 2012 (Part 6) – Monitors”

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top