An interface flap can produce dozens of observations: link-state changes on two devices, routing-neighbor resets, traffic shifts, congestion, CPU changes, and downstream reachability failures. Treating every observation as a separate ticket wastes investigation time. Treating all simultaneous observations as one incident is equally dangerous.
Correlation is not deduplication
Deduplication asks whether two events are effectively the same event. Correlation asks whether different events share a causal context. A repeated interface-down notification might be deduplicated. A BGP reset following that interface failure may be correlated, but it is not a duplicate.
Signals that support correlation
- Topology: the resources share a physical, routing, or service dependency.
- Time: the sequence is compatible with the proposed cause.
- Direction: the upstream signal changes before the downstream symptom.
- State transition: the observation represents a meaningful change, not a repeated poll.
- Recovery: dependent symptoms clear when the proposed cause clears.
- Contradictory evidence: independent failures are kept separate when topology or timing does not fit.
A useful incident needs a deduplication key
The key should describe the condition and resource, not just a human-readable message. It normally includes tenant, detector, device or resource, interface or neighbor where relevant, and lifecycle state. Tenant must be derived from authenticated context, never from a payload supplied by the source.
Do not correlate on device names alone
MSPs and large enterprises routinely manage devices named core-01, edge-01, or fw-01 for multiple customers or sites. A bare name is not a globally unique identifier. Correlation stores, topology, application mappings, and real-time delivery must remain tenant-scoped even when names collide.
Measure false grouping as well as noise reduction
A system can produce an impressive reduction percentage by grouping too aggressively. A credible benchmark includes independent faults in the same time window and checks that they remain separate. Report both notification reduction and false cause-and-effect links.
Questions to ask a vendor
- What evidence causes two alerts to be correlated?
- Can the operator see why an event was included?
- What keeps independent failures separate?
- How are recurring incidents reopened?
- Are acknowledgment and ownership different fields?
- Does a recovery clear the incident, and can it reopen safely?
- How are tenant collisions tested?