告警静默与抑制：静默规则、抑制规则、持续时间设置
告警一直响，到底哪些该处理？
我记得刚接手线上运维那会儿，凌晨三点被告警轰炸是常事。后来我悟了——不是所有告警都值得你从被窝里爬起来。真正需要你关注的，是那些代表「真实故障」的信号。
这节课，我们来聊聊怎么把告警噪音降下去。核心就两个手段：静默和抑制。听起来像一回事？其实思路完全不同。
一句话总结：
静默是「我知道你要报警，但我现在不想看」。
抑制是「我知道你报警了，但上级告警已经代表了问题，你就不用再报了」。
什么是告警静默
静默，说白了就是主动屏蔽。运维人员可以提前声明：「接下来X小时，这个组件的告警我包了，你们别吵我。」
我在项目中遇到过一种场景：SRE团队要进行数据库主从切换，操作期间会短暂出现复制延迟告警。如果不去静默，全组都会收到误报。你想想看，半夜看到这种告警，心里得多慌？
静默规则一般包含这几个字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 匹配条件 | 指定哪些告警会被静默 | alertname="MySQLReplicaLag" |
| 作用域 | 按标签、实例、集群过滤 | cluster="prod-db" |
| 计划窗口 | 开始时间 + 持续时间 | 2025-04-10 02:00 ~ 03:00 |
| 创建人 / 原因 | 谁建的、为什么 | zhangsan / 主从切换维护 |
我个人习惯给每条静默规则加上到期自动清理。否则你会发现，三个月前的维护静默还挂在系统里，新来的告警被误伤。嗯，这里要注意。
# PrometheusAlertManager 静默规则示例
silence:
- matchers:
- name: "alertname"
value: "InstanceDown"
startsAt: "2025-04-10T02:00:00Z"
endsAt: "2025-04-10T03:00:00Z"
createdBy: "zhangsan"
comment: "计划内机房UPS测试，预先静默下线服务器告警"
什么是告警抑制
抑制是自动的。不需要人去创建规则，而是基于告警之间的依赖关系自动判断。
举个例子：你的核心交换机宕机了，下挂的100台服务器全部不可达。如果没有抑制，你会收到101条告警。但实际上，你只需要处理交换机那一台。其他的告警都是「因为交换机挂了才出现的」，属于衍生告警。
抑制规则的核心机制就是：如果存在一级告警（根源），则自动压制下级告警（衍生）。
实现方式主要有三种：
- 基于依赖的抑制：预先定义依赖关系，比如A服务依赖B机器。
- 基于主机/集群的抑制：所有归属于同一主机的告警，被主机级别告警压制。
- 基于标签的抑制：给告警打标签，抑制时匹配标签继承关系。
我记得有一次线上出了个棘手的问题：某台物理机风扇故障，温度告警一直触发，但集群控制面还在。结果无抑制规则，温度告警和宕机告警同时往值班群刷屏……最后值班同事被冲昏头，漏掉了真正的磁盘坏道告警。
曾经踩过的坑：
抑制规则不能写得太宽泛。我见过有人把「severity=warning」全部抑制，结果业务层面容量预警被压了三天，最后直接线上事故。抑制务必保留一条永远不抑制的高危通道 —— 比如 P0 告警直接跳过所有抑制逻辑。
# PrometheusAlertManager 抑制规则示例
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['cluster', 'host']
- source_match:
alertname: 'NodeDown'
target_match:
alertname: 'NodeHighCPU'
equal: ['node']
持续时间的设置逻辑
静默和抑制都涉及「这个压制要持续多久」的问题。设置太短，告警又冒出来；设置太长，真正的问题可能错过了。
我一般遵循这几个经验数值：
| 告警类型 | 建议静默持续时间 | 备注 |
|---|---|---|
| 计划内维护 | 维护窗口 + 15分钟缓冲 | 防止操作延时 |
| 突发临时操作 | 30分钟 | 短平快 |
| 已知问题临时豁免 | 2~4小时 | 需关联工单，到期自动取消 |
| 抑制（衍生告警） | 直到根源告警恢复 | 不要设置固定时长，而是跟根源告警生命周期绑定 |
关于抑制的持续时间，我建议不要用固定一小时的窗口。根源故障可能持续三小时，你设一小时的抑制，后两个小时新告警又飞出来了，值班人员会疯掉。抑制必须绑定根源告警的状态 —— 根源告警恢复了，抑制才自动解除。
你想想看，如果设置成固定时长，一旦根源没恢复，产生的新衍生告警不会被压制，等于抑制失效。说白了，抑制的核心不是「压多久」，而是「根源在，压制就在」。
实战避坑
- 不要用手动静默替代故障排查——我曾经见过同事把同一个告警静默了三次，结果第三次静默到期后组件真的挂了，后悔也晚了。
- 抑制规则一定要测试——伪造一个根源告警，看下级告警能不能被正确压制。我见过抑制写反了，把根源告警压掉，衍生告警全爆出来的惨案。
- 静默规则必须留痕——谁建的、什么原因、什么时候到期，这些信息必须写入监控系统。否则团队内卷，互相甩锅。
经验之谈：
静默适合「我知道可能有告警，但我不需要处理」。
抑制适合「可能有告警，但它不是根因，我不应该看它」。
两者同时用，大概率能把告警噪音降到80%以下。但别忘了——监控系统的终极目标不是让你清净，而是在真正出事时，你能第一眼看到真正重要的那条告警。
嗯，这一块讲完了。下次遇到告警刷屏，先问问自己：这些告警里，哪些是「我主动屏蔽的」？哪些是「被其他告警压制的」？分清楚这两类，你的值班体验会好很多。