Superseding incident example
Superseding occurs when one incident replaces another incident (or potentially multiple incidents) because correlation has resulted in the incidents having an alert in common. Whether the incidents can merge or not depends on correlation group settings; specifically, the Automatic Merge setting. The replaced incident is assigned the superseded status, and the incident fields are locked to the values they contained when the incident was superseded. For more details on superseding, refer to Understand superseded incidents.
An incident is superseded by another when two or more incidents meet the merge threshold for their correlation group and include at least one alert in common. The following example shows how an incident in APEX AIOps Incident Management can be superseded by another.
In this scenario, there is one correlation group. The settings are the system defaults with these two setting changes:
Automatically merge incidents when 10% of the alerts match.
Alerts can match all correlation definitions is selected
The correlation group has two correlation definitions:
Definition 1
Scope filter:
service!= databaseMatch the
descriptionfield at 100%Alert threshold = 1 (Immediately create on first alert is selected)
Definition 2
Scope filter:
service!= storageMatch the
descriptionfield at 100%Alert threshold = 1
There are two incidents with alerts containing the indicated values:
Incident 1 | |
Alert IDs | Values |
|---|---|
Alert 3 | "description": "Application failure",
"service":[
"storage"
] |
Incident 2 | |
Alert IDs | Values |
|---|---|
Alert 4 | "description": "Application failure",
"service":[
"database"
] |
A new incoming event then creates Alert 5 with this information:
"description": "Application failure", "service":[ "logging" ]
Alert 5 matches the scope for both correlation definitions, and so it is placed in both Incident 1 and Incident 2. Then, because the Incidents 1 and 2 are similar, they are merged together according to the Automatic Merge setting for the correlation group (which was set to merge at 10% similarity).
Merging occurs after correlation, so the correlation scope does not affect the ability of the incidents to merge.
Incident 1 includes three alerts, as shown:
Incident 1 | |
Alert IDs | Values |
|---|---|
Alert 3 | "description": "Application failure",
"service":[
"storage"
] |
Alert 4 | "description": "Application failure",
"service":[
"database"
] |
Alert 5 | "description": "Application failure",
"service":[
"logging"
] |
Incident 2 includes these two alerts, and it has the status superseded.
Incident 2 | |
Alert IDs | Values |
|---|---|
Alert 3 | "description": "Application failure",
"service":[
"database"
] |
Alert 5 | "description": "Application failure",
"service":[
"logging"
] |
At this point, Incident 1 contains all of the information that Incident 2 contains, plus it also contains Alert 4. It more completely represents the issue than Incident 1. Incident 1 is now redundant, so it is superseded by Incident 2.
See Understand superseded incidents for more on superseding.