As ServiceNow expands its IT Operations Management portfolio, I'm starting to see Event Management gaining traction with our customers. In the upcoming weeks, I'd like to demystify and showcase the various aspects of Event Management and hopefully give you good tips along the way!
So what is ServiceNow's Event Management all about?
Well, it's all about noise reduction! Many people today think of ServiceNow as the ticketing system where they'll simply open up an incident for a given event. For the most part, this process generates way too much noise and brings almost no value. With ServiceNow's Event Management, the goal is to bring in events from different monitoring tools, and then apply noise reduction techniques -- such as filtering, transformation, consolidation, and de-duplication -- before creating an incident. This process essentially creates a funnel so that by the time a human engages with the system, the created incident is already vetted properly.
Here is an example of what that looks like (figure credit goes to Tony Branton, an expert for all things Event Management):
In ServiceNow speak, an "event" is data coming from monitoring tools (as you can see in the diagram) whereas an "alert" is an event that has gone through the first phase of noise reduction processes. In other words, "alerts" come from "events" that have gone through the "weed-out" process, so that an alert is generally considered as something that is potentially actionable.
So what dictates the "weed-out" process? We use "Event Rules". For more information on how to use Event Rules, please refer to Tony Branton's post on Become Awesome with Event Rules, where he goes into details on how to make this all happen.
Now, what is an example of how an event rule could be used? Well, you could use it to filter out events that aren't important based on a low priority value or based on its type (e.g., informational). Or you could create an alert only when the CPU usage has been consistently going above 95% over the span of 5 minutes. There are endless possibilities. And keep in mind that this could be generalized to more than just traditional IT infrastructure monitoring. I have personally seen very creative use cases around ATM transactions or card reader failures where you'd only want to create an alert when a specific set of events have transpired.
In my experience, with proper setup of event rules, it's not uncommon to see an event compression ratio of around 95% or more. For example, similar events (e.g., CPU over 95%, disk space usage over 90%, etc) for the same target should logically be grouped as the same alert; events with updated severity (going from minor to major) should be grouped as the same alert; or maybe you have redundant event monitoring tools that are throwing the same events from the same target -- those should be consolidated into the the same alert as well.
So how does this all work technically? The ability to de-duplicate and consolidate events is done through what we call the "message key", which is nothing more than just an identifier for a given event. And all events with the same message key are consolidated into the same alert. When all is said and done, the magic is about leveraging the event rules to properly construct the message key for each event in order for the events to consolidate correctly. By default, ServiceNow Event Management generates a message key automatically based on the node, source, type, and resource of the event record, but you could absolutely create your own message key based on any set of event rules that your heart desires. There is no "one size fits all approach", so I highly recommend going through the Event Management training offered by ServiceNow.
Lastly, I'm often asked what monitoring tools we're able to integrate with, which is addressed with another blog post A List of Event Management Integrations by Tony Branton (again!).
For now, this is a wrap! In the next post, we'll explore more about alerts and how they work. Until then, stay tuned!
1 Comment
