Incident Aggregation¶

Incident aggregation groups events that meet the same rule and share the same aggregation key-value pairs into a single incident, reducing duplicate incidents generated by concentrated triggering of similar events. You can create and manage rules in Incident Center > Config Management > Aggregation Rules.

Each rule can only use one aggregation method: Aggregate Events by Time Window or Monitor-Associated Incidents. These two methods are not executed simultaneously. Multiple rules can exist in one workspace. When an event matches multiple enabled rules, it will participate in the aggregation of each rule separately.

Configure Aggregation Rules¶

1. Go to Incident Center > Config Management > Aggregation Rules, and click Create.
2. Fill in the rule name and select the incident aggregation method.
3. Set event filter conditions and aggregation keys.
4. Supplement the time window or monitor association configuration according to the selected method.
5. Configure the incident level generation strategy and incident content display rules.
6. Save and enable the rule.

After a rule is disabled, subsequent events will no longer be processed by this rule. Incidents already generated and their associated events will not be deleted or recalculated.

Select Aggregation Method¶

Aggregate Events by Time Window¶

• The time window is required, supporting 1, 5, 10, 15, 30, 60 minutes.
• The system processes windows based on natural minute boundaries, for example, a 5-minute window is [10:00, 10:05), [10:05, 10:10).
• Only processes events within the current workspace that fall within the window and meet the filter conditions, including events forwarded from other workspaces that can be queried in the current workspace.
• A level mapping must be selected. Events that do not match a level mapping will not participate in aggregation.
• When the same aggregation identity appears in a subsequent window, the same active incident will be updated. If the original incident has been recovered or closed, a new incident will be created.

Monitor-Associated Incidents¶

• Only processes events generated by monitors with the Associate Incident feature enabled.
• The time window configuration is not displayed or saved.
• You can select Custom Mapping or Select Existing Mapping Rule in the monitor. Existing and newly created monitors use custom mapping by default, and the original mapping relationship remains unchanged.
• When selecting an existing mapping rule, a level mapping must be selected. Events that do not match the mapping will not participate in incident aggregation.

Set Event Scope¶

Events must meet the rule's filter conditions to participate in aggregation. The filter conditions reuse the event filtering capability and can be filtered by event fields. For example, using service:trade-api AND env:prod limits the scope to events from the trade-api service in the production environment.

Rule modifications only affect events entering the processing chain and subsequent windows after the modification. Historical events, generated incidents, or historical association relationships will not be recalculated.

Set Aggregation Keys¶

Aggregation keys determine which events are grouped into the same incident. The system identifies the same group of events based on "rule + aggregation keys and values arranged in the configured order."

• Each rule must be configured with at least 1 aggregation key and a maximum of 3 aggregation keys.
• You can search and select first-level fields from event fields, such as df_workspace_name, host, service.
• Manual input of second-level field paths is supported, for example, df_dimension_tags.host, df_workspace_declaration.CODE. After input, the path will be saved and displayed in its entirety.
• If any aggregation key does not exist, is empty, or is null, the event will not participate in the current rule.
• It is recommended to select fields that are stable and can represent the incident object. High-cardinality fields like timestamps or request IDs may generate a large number of independent incidents.
• Events with the same key name and value within the same rule will be grouped into the same active incident. Different rules, even if they use the same keys and values, will generate incidents separately.

Set Level Mapping¶

Level mapping converts event levels into incident levels and can be reused by time window aggregation rules and monitor-associated incidents. First, create mappings in Incident Center > Config Management > Level Mapping, then return to the rules or monitors to select them.

• One event level can only be mapped to one incident level, and at least one mapping relationship must be configured.
• It is available immediately after creation. Modifications only affect subsequent events and subsequent windows, and will not retroactively affect generated incidents.
• Mappings referenced by aggregation rules or monitors cannot be deleted. All references must be removed first.
• Level mappings themselves do not have an enable/disable status.

For more configuration details, please refer to Level Mapping.

Set Incident Level Generation Strategy¶

Set Incident Content Display Rules¶

Under the custom rule, if the incident title is not filled in, the system will use the title of the first triggering event.

View Aggregated Incidents¶

Incidents generated by aggregation rules are marked as Aggregated Incidents and can be filtered by incident type in the incident list. The associated events in the incident details are based on the relationships recorded during the actual aggregation. Therefore, subsequent modifications to the rule's filter conditions or aggregation keys will not change the historical associated events of the generated incident.

Incident notifications, Webhooks, and third-party ITSM pushes follow the existing process. When the associated events of an aggregated incident change, if the Webhook has checked the Aggregation Change event, the system will push the latest incident and associated event snapshot.