The perfect recipe for managing SCOM alerts
In SCOM you can see the monitoring that generates your alerts (the contents of Health Explorer). While SCOM doesn’t always make it easy to get at the valuable context that this monitoring data provides, it is there and can help answer the "why" questions that often come up when looking at an alert in isolation.
"Are there any other issues impacting this server?"
"What is the impact of this disk being full?"
"What runs on this server?"
Giving SCOM alerts context
SquaredUp dashboards help provide this context in an easily consumable form by mining, valuable monitoring data and slapping it right next to those alerts, see the example below:
Make alerts Incidents
The Manifesto for SCOM Success, first laid out at SCOMathon 2020 back in June, states that ingratiation is a vital part of SCOM success.
Why? SCOM is great at raising those alerts but is poor at facilitating their resolution.
SCOM’s primary method for notifying users of an alert is mail, which is fine when you only have a few alerts, but anyone who has actually used SCOM will know this isn’t manageable when staring at an inbox with thousands of mails in it, all of which need to be read to understand their priority and context. Initially a SCOM admin will simply solve this issue by living in the SCOM console, which allows alerts to be sorted and grouped, but good luck on getting domain experts (i.e. the folk who actually need to fix the issues) to open the SCOM console.
SCOM's primary of consuming alerts, mail, simply doesn’t work alone. SCOM has no workflow system for managing the alerts once raised. They have "Resolution State" but, this is little more than a text field with; no automatic reminders, owners assigned, SLAs or clear escalation path.
ServiceNow (or your ITSM system of choice) has workflows designed for handling exactly this issue. Incidents can be routed to the right team based on smart logic; this means they can be integrated with SLAs, escalated based on priority through service maps and use the appropriate method for alerting the people who need to fix the issue (e.g. phone call for P1s, text for P2s and mail for P3s).
All of this means you stand a chance of delivering ITIL based on SCOM alerts.
The case for joining these two worlds is clear! SCOM alerts > Incidents have a much greater chance of being looked at and actioned.
If you have SCOM and ServiceNow, the good news is Cookdown Alert Sync can plug your alerts into ServiceNow with minimal work, more on how to do this is here.
If you use another ITSM system, check out our blog on pushing SCOM alerts to rest endpoints, which provides guidance on how to build something similar for other ITSM tools.
Problems solved? Not quite.
End to end visibility
Now you have SCOM alerts as Incidents, hopefully they are being actioned, but the insight you gained by using dashboards is no longer "end to end", as not all the data lives in SCOM. This means you’ll need to keep flicking between your SCOM dashboard and ServiceNow incident lists (which needs filtering to find the Incidents you are interested in looking at).
Luckily, SquaredUp has the answer! Using Cookdown’s Alert Sync's bi-directional sync feature, Incident data can be pulled back into SCOM alerts. This allows you to show Incident and Alert data in the same place in tiles like this:
These enriched alerts can now be pulled into your dashboards for true end to end visibility – you now have monitoring data from SCOM (context), alerts and incidents side-by-side, all configured to your needs , all scoped appropriately so that you only see the data you care about. No more "swivel chair monitoring" and no more manually configuring Incident lists to the correct scope!
If you would like to set up these solutions in your business, then good news! You can get a free 30-day trial of Alert Sync for ServiceNow and SquaredUp’s dashboards for SCOM, at the links below:
Happy Monitoring!