Similar Incidents overview
The Similar Incidents feature lets you configure the calculation which determines the information on the Situation Room Recommendations tab. This tab lets you see a list the incidents in APEX AIOps Incident Management that have the most similar alerts to the currently viewed incident.
The value of similar incidents
By reviewing the incidents in the list, you can view the steps used to resolve past incidents (and incidents which are being resolved concurrently) that are like the incident of interest. Following the same steps used to resolve a past incident can reduce the time needed to resolve new incidents.
Viewing alerts in the similar incidents can also reveal patterns which indicate chronic issues with a device, a service, or some other component contributing to incidents or causing them to occur. The information provided can help you track down the sources of these incidents and prevent a recurrence in the future.
Additionally, users looking for the most recent information on incidents can also find information on similar, possibly related, incidents.
Note
Remember that comments are key to understanding how a past incident was resolved. Be sure to mark resolving steps in the comments when resolving an incident.
Configure incident similarity
To configure incident similarity, navigate to Correlate & Automate > Similar Incidents.
There are three options for calculating incident similarity:
Alert deduplication key (recommended)
This key is always composed of the fields
source
,service
,check
andclass
, unless a different deduplication key is specified in the payload (such as for a custom (CYOI) integration).Because these fields are already used to determine alert uniqueness, the alert deduplication key is the recommended option. Using this option generally provides the most consistent similarity across the application, and it is the setting used by default for Incident Similarity.
Default fields
The default similarity calculation uses the fields
check
,manager
,class
, andtype
.Custom similarity calculation
Select a custom group of alert fields to use to compare similarity.
You can use any combination of the following fields in the similarity calculation:
check
,service
,alias
,manager
,manager_id
,class
,type
, and individuallocation
fields.Warning
Use the custom setting with caution as the way incident similarity is determined will change dramatically with custom fields.
If you change the setting to a different list of fields, the changes are reflected in your system right away. The recalculation process takes anywhere from a few seconds to a few minutes, depending on the number of alerts and incidents in the system.
After making the change, access incidents via the Situation Room and see if the incidents on the Recommended tab show the similarity that you want to achieve.
How incident similarity is determined
The first step in determining incident similarity is to compare the alerts in incidents to determine which alerts are similar. Incident Management checks alerts for the values in the fields defined in the Similarity Calculation. A similarity key made up of alert values is produced for each alert, which allows alerts to be compared.
In this example, the Similarity Calculation uses the default alert deduplication key values to create the similarity key:
source
service
check
class
Consider these three alerts:
Alert 1 | Alert 2 | Alert 3 |
---|---|---|
{ "source" = "172.16.5.5", "service"= "Compute", "check" = "host_disk_reads_completed_total", "class" = "Storage" } | { "source" = "172.16.200.3", "service" = "Compute", "check" = "system_disk_free", "class" = "Storage" } | { "source" = "192.168.35.7", "service" = "Network", "check" = "system_disk_used", "class" = "Storage" } |
Alert 1 : 172.16.5.5:Compute:host_disk_reads_completed_total:Storage
Alert 2: 172.16.200.3:Compute:system_disk_free:Storage
Alert 3: 192.168.35.7:Network:system_disk_used:Storage
The similarity keys for two alerts must have the same values for the alerts to be a match. The calculation doesn't consider partial matches for alerts. Therefore, only other alerts with the similarity key host_disk_reads_completed_total:AWS:Storage:Activity will match Alert 1.
When an incident is viewed in the Situation Room, the similarity key for every alert in the current incident is compared to the similarity keys for all other alerts in all other incidents. Alert similarity keys must match exactly to be considered a match.
The Jaccard index is used to determine incident similarity. In the Jaccard index paradigm, the incident has the role of the group, and the alerts are the group members. Based on the information provided in the alert comparison step using similarity keys, the incidents are compared and assigned a similarity score. If this score is 70% or greater, then the incidents are considered similar.
Note
The process of comparing two groups using the Jaccard index is complex and beyond the scope of this documentation. For detailed information on how this process works, see this Wikipedia article.