SCOM Rules vs Monitors

If I had a dollar for every time I was asked "What's the difference between a Rule and a Monitor" I'd have at least $7. In all seriousness though, Rules vs Monitors is a question that raises it's head every time someone new enters the SCOM Arena.
So we have Rules, we have Monitors and from the outside looking in, they look pretty much the same and yes there are a few similarities, but it's the differences you really should concern yourselves with.

Here's the short version:

Monitors track the State of an Object and only store State Changes and Alerts in the "Operations Database".
Rules can collect data from scripts and raise alerts and store their data in the "Operations Database" and the "Data Warehouse" so it can be reported on.

And here's the long version

Monitors    track    the    State   of   an    Object   and   only    store    State    Changes   and    Alerts    in   the    "Operations      Database".
Rules    can    collect    data    from   scripts   and    raise   alerts    and   store    their   data    in    the   "Operations   Database" and    the    "Data    Warehouse"    so   it   can   be   reported   on.

Right, so we've established that my humor is spot on today…so let's continue.

Monitors

Monitors work in Real Time (well almost real time – they're pretty quick to update). So when a monitored object goes from Healthy (Green) to Warning (Yellow) or Warning to Critical (Red) or Critical to Healthy or anywhere in-between based on it's change in State, we're talking about a Monitor.

That's really what Monitors do, they track changes in State. As such you'll often hear of them referred to as "State Machines" or "State Monitors" or something with an expletive attached (such is the life of the enterprise monitor-er (if that's even a word)).

Monitors also show up in the "Health Explorer". The Health Explorer can be found when you right click on an Alert in the Console and choose "Open –> Health Explorer" or you can select it from the "Actions Pane" on the far right of the SCOM Console.

When you fire up the Health Explorer you'll see something that looks like this…

Looks pretty nice huh?

Also notice that there are some monitors showing a green tick . This means that the monitor is healthy (Hooray!)
Other Monitors have no tick at all . This means that the monitor is not running (Boo…well, unless you put it in maintenance mode or Group Calculations haven't run yet, then Yay!)
You might also see monitors showing a Yellow Exclamation Point . This represents a Warning.
And we could also see a Red X . This means that there is something wrong and you should immediately pay me to fix the problem

Since I'm on the subject of icons, there's also a "Gray" icon as well  and this represents an Agent that is not doing what it's supposed to do and probably needs a little TLC to fix it. If you have gray agents then you'll probably get alerts in your console like this one…

and in your OpsMgr Shell like this one

Chances are though, a simple "Net Stop HealthService" and "Net Start HealthService" on the Agent Computer will flip that Gray to Healthy!

If it doesn't fix your Gray Agent then you might want to check out Microsoft Article 2288515, or Kevin Holman's Blog, both do a fine job explaining why your agent might be gray.

So back on topic now, Monitors and Rules…notice on that last screenshot there was this line…

Wondering if this Alert was generated from a Monitor or a Rule? Dead giveaway really. It's a Monitor. Whenever you see "IsMonitorAlert : True, then it's a monitor that generated the alert. "IsMonitor : False" tells us that it's a Rule.

Rules

A rule is a workflow that applies certain rules. Unlike monitors a rule is not used to the alter state of an object. Earlier in this post I referred to Monitors as being "State Machines". Well, a rule can be thought of as a "Stateless Machine".

It's very common to use rules when you want to collect data about objects, such as performance data for example. And yes, rules can generate alerts but they don't generate alerts about state changes.

A Rule must define at least one write action. This could be to run a script or generate an alert, but in most cases you'll write the data to the data warehouse server via a mapping module (if the data is Alert, Event or Performance Data).

A Rule must be one of these Categories:

PerformanceCollection
Operations
EventCollection
StateCollection
SoftwareAndUpdates
Alert
Custom
AvailabilityHealth
PerformanceHealth
ConfiguraitonHealth
SecurityHealth
Notification
Maintenance

Rules differ from Monitors in that you won't see them in the Health Explorer. Seriously…create a rule and look for it in the Health Explorer…it won't be there because the Health Monitor only shows "State Changes" which Rules are not used for.

Rules also allow us to store data in the "Data Warehouse" server. If you don't have a data warehouse server yet, it's just another SQL Server where we'll store captured data and hang onto it for a much longer period. We can then use this Data Warehouse to produce reports against the data stored. The reason we don't want to keep a large quantity of performance data or event collection data in the day-to-day "Operations Database" is that it will grow quickly and slow the performance.

Rules can generate Alerts just like Monitors.

To summarize

So to make this a little clear(er).

Monitors are used to monitor state changes. So if an object changes between on/off, up/down, red/green, healthy/critical then we are talking about monitors. The state is changing. Right now it's up, soon it's down. That's a monitor. We cannot store this data in the data warehouse. Monitors do appear in the Health Explorer.

Rules are not going to monitor state. So a rule can look for an event in the event log. It can trigger when performance counters are exceeded (ie, CPU is over 80%, less than 100Mb Memory etc.) This data can be stored in the Data Warehouse. Rules do not appear in the Health Explorer.

Both Monitors and Rules can generate alerts. Monitors only generate alerts when the state has changed. Rules can alert when values are reached or a specific event occurs.

So which should you use?

Well ask yourself if you need to report on the events you wish to monitor. If you do, then you need a rule. Is there a State Change involved? Does the object being monitored go on/off, up/down, healthy/critical, do you want to see a Healthy Green Tick or a Critical X in the Health Explorer? Then a Monitor is what you need. Chances are though, you'll be creating a lot of both of them.

Monitors Rules