告警太多和没告警一样危险。本文介绍炬鲸 OBSERVE 如何通过分组、去重、分级、值班轮换和静默窗口，把每天几千条告警收敛成几十条可行动事件，并给出可直接套用的配置示例与落地建议。
运维最怕的不是没告警，而是告警太多。一个数据库节点抖动，可能同时命中连接池、慢查询、磁盘 IO、服务可用性四条规则，几秒内刷出几十条消息。值班同学看着满屏红点，既分不清哪个是根因，也不敢随便关。日子一久，告警变成「狼来了」，真出事反而被淹没。
这不是危言耸听。我们统计过一批客户的历史数据：一个中型团队每天的原始告警普遍在 2000 到 5000 条之间，但真正需要人介入的往往不超过 30 条。剩下的 99% 是重复、抖动和低价值提醒，它们唯一的作用是消耗值班人的耐心，让他在凌晨三点把手机静音。
炬鲸 OBSERVE 的告警引擎把主要精力放在两件事上：先把海量原始告警收敛成少量可行动的事件，再把每个事件准确送到该处理的人手里。收敛靠分组和去重，送达靠分级和路由。
分组基于标签维度自动聚类。同一服务、同一主机、同一指标在一个时间窗口内触发的告警，会被合并成一条聚合事件，事件里保留触发次数和峰值，而不是逐条推送。配置很短：
group_by: [service, host, alertname]
group_wait: 30s
group_interval: 5m
repeat_interval: 4h三个参数各管一段：
group_wait：首次告警后等 30 秒再发，让同一波抖动归并成一条group_interval：同一分组内新增告警，最多 5 分钟提醒一次repeat_interval：未恢复的告警 4 小时才重复提醒，避免整夜刷屏去重解决的是「同一条告警反复发」的问题，分组解决的是「一批告警其实是同一件事」的问题。两者叠加，效果才明显。比如一次网络分区可能让 40 台主机同时报「心跳丢失」，去重后仍是 40 条；但如果按「故障域」分组，这 40 条会被合并成一条「机房 X 网络异常」，值班人一眼就知道该找谁。
效果好坏取决于标签设计的质量。粒度太粗（只按 service 分组），不同主机的故障会被错误合并；太细则收敛不下来。建议从 service + host 两级起步，跑一周看数据，再根据「哪些告警总是同时出现」来补标签。
按严重程度分 P0-P3，配不同的通知渠道和接收人：
分级的依据不是「你觉得重不重要」，而是「出事后谁在什么时候必须知道」。一个判断标准：如果这条告警半夜打给你，你愿意起来处理吗？不愿意，就降级或改成仅记录。
路由的另一个关键是值班表。告警应该打到当班人，而不是全员。炬鲸 OBSERVE 支持轮值排班，交接自动切换接收人，避免告警打到已下班的同事手机上。跨团队场景还可以按服务路由：支付系统的告警进支付团队的值班群，订单系统的告警进订单团队，互不打扰。
发布窗口、压测、已知故障期间，把相关告警静默，避免误导。支持按服务、主机、时间段配置静默窗口，到期自动恢复。比如凌晨 2 点的例行备份，可以把对应的磁盘 IO 告警静默 30 分钟，而不是每晚叫人起来看一条本来就没问题的告警。
一个常被忽略的细节：静默窗口最好和变更管理联动。发布时自动开启静默，发布结束自动关闭，而不是靠人记着去开、去关。手动静默最大的风险是「忘了关」，导致之后真故障被静默掉。