Evanios Operations provides multiple ways to achieve deduplication and event correlation ServiceNow. In addition to deduplicating multiple events into a single event, multiple events can be correlated and consolidated into a single ServiceNow incident ticket.
For example, let’s say I have several events occurring on a Windows server that I believe to be related, and Windows servers are supported by a single team. I might want to first deduplicate events that are truly duplicates, but then similar events I would like all to be seen on a single incident ticket. The logic here is to give the Windows team a single incident ticket with all the information they need to restore service.
The Deduplicate Rule
First we need to create a fairly standard deduplication rule. In this case, our data is being normalized into the common event format, so all we need to do is define which fields are similar and indicate a duplicate.
This rule deduplicates events that match the event filter and have matching values in “ObjectName” (host), “Application”, “Instance”, and “Parameter”. These four fields represent the standard markup for a unique object in our common event format. (We will do a deep dive blog on common event format later this month). event correlation ServiceNow
We’ve also selected the following behavior when a duplicate is identified:
- Drop the new incoming, duplicate event (throw it away, it’s a dupe!)
- Update the repeat count of the old event (how many of these things did I get?)
- Use the latest severity value (so if the latest incoming event is critical, let’s mark the existing event critical)
So, at this point we’ve collapsed multiple similar events into single representative events. On to phase two.
The Trigger Incident Rule
To create incidents from events, we create a trigger incident rule. We can have several options which help us control exactly how the ticket is created and updated.
Here is a trigger incident rule that will create the initial incident from the first event matching the event filter. It will also update that existing incident with subsequent events that match the filter AND have a matching field of “ObjectName” (host). So if I have a CPU, Disk, and Memory event for a single host, these will all end up on the same ticket. The initial event will be described in the short description, and subsequent events will be added to the work log field in the incident.
Using these two simple rules, we’ve created correlated incidents in ServiceNow that represent multiple technology failures on a single server. Our Window team is ecstatic since they have 70% fewer incident tickets, and tickets are more meaningful, providing a complete picture of the incident occurring on that server.
While this may or may not be a realistic scenario within your environment, Evanios Operations allows easy form based configuration of complex event management scenarios like this one.
For more information on how Evanios Operations rules work, documentation is available on our documentation wiki. event correlation ServiceNow