Skip to main content

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 and class, unless a different dedupe 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, and type.

  • 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 individual location 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.

Example 1. Similarity keys

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"
}
. Similarity keys
  • 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.