On-call receives an alert storm from one root failure cascading across municipal microservices. What observability practice reduces duplicate pages from that single incident?
Select an answer to reveal the explanation.
Short Explanation
One snapped power line can make every house’s lights blink—and every detector scream. Correlation groups those screams so on-call sees one incident, not fifty clones. Without it, cascade failures bury the root cause under noise.
Full Explanation
Correlating or aggregating related alerts so one root failure does not generate an unmanageable storm of duplicate pages protects on-call when a single fault cascades across municipal microservices. Paging a separate engineer for every identical child alert with no grouping multiplies fatigue without new information. Suppressing all future alerts for thirty days after any storm blinds the city to new incidents. Converting each alert into a printed poster hung in city hall fails real-time operations. Exam caveat: alert correlation/aggregation reduces duplicate pages from one root cause; suppression windows are not a substitute. Operational check: group by root service or correlation id, keep a parent incident, tune dependent alerts, and measure pages-per-incident. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate. Confirm monitoring, access reviews, and backup coverage still align with the selected approach before closing the civic hypercare period.