In OpsMgr 2007 and 2012, alerts are generated by either monitors or rules. Monitors are used to represent the health of a component while rules are generally used to collect data, yet they can generate alerts as well. Many OpsMgr operators that focus their efforts on resolving issues in their environment often do not make the distinction between the two mechanisms for generating alerts and will sometimes close long standing alerts to “see which alerts are being raised again”.
The TechNet library has a good entry on the impact of closing alerts generated by monitors or rules, but here’s the crux of it:
Manually closing alerts raised by monitors is generally bad practice. Monitors will not raise an alert again unless their state goes back to healthy then to unhealthy.
Why is this bad? Well, for one thing, the health model of a particular component goes out of sync with reality – this means that what you see in OpsMgr doesn’t reflect reality. This reduces the effectiveness of OpsMgr and the value of centralized monitoring.
The reality of many IT Monitoring teams, however, is that not every alert can be attended to, especially during periods of transition such as an influx of new servers/applications or the introduction of a new management pack (i.e., the tuning or stabilization period).
To help you during those times, wouldn’t it be nice to have an alert view that tells you which alerts have been raised by monitors and which alerts have been raised by rules? In OpsMgr 2012, you can do that thanks to widgets.
Note: in OpsMgr 2007 and later you can find this information in the alert details. In this post, however, you’ll create a view so that you can see at a glance the split between the two types of alerts.
The dashboard view will now display alerts grouped by monitors (Is Monitor = True) or rules (Is Monitor = False).
This view will now help operators and support personnel triage the alerts a bit further.
Hope this helps! Comments are welcome!
Thanks Michel , this is something I will use in my day to day.