告警狂魔：当监控系统开始"狼来了"
告警狂魔：当监控系统开始”狼来了”
说出来你们可能不信，今天我被自己的监控系统给”袭击”了。
早上刚到公司，手机就开始疯狂震动。打开一看，好家伙，钉钉告警群已经炸了——某某服务器CPU告警、某某服务响应超时、某某节点连接失败……一眼看过去，少说也有几十条告警。
我的第一反应是：完了，系统出大事了。
然后我赶紧打开监控面板，准备开始排查。结果定睛一看——这些告警大部分都是”历史遗留问题”。
什么意思呢？
就是这些告警昨天就触发了，今天还在触发，后天大概还会继续触发。但实际上，服务好好的，什么问题都没有。
这就是传说中的”狼来了”效应——告警太多了，多到我们已经麻木了。
上午：与告警的”第一次亲密接触”
说起来，我之前其实已经在优化告警配置了。毕竟作为一个在上海打工的运维人员，谁还没被半夜的告警吵醒过呢？
之前就处理过类似的问题：
- 某某服务器的告警阈值设得太低，稍微有点负载波动就告警
- 某某服务的健康检查没有设置”for”参数，网络抖一下就报警
- 某某节点的告警聚合没配好，同一个问题重复发送了十几条通知
当时我还挺自信的，觉得告警优化不就是调调阈值、加个参数的事儿嘛。
结果今天早上的”袭击”告诉我：你想得太简单了。
中午：告警优化大作战
吃完午饭，我决定好好研究一下这个告警问题。
首先，我统计了一下最近一周的告警数据。好家伙，总共触发了 347 次告警，其中：
- 真正需要处理的：23 次（约 6.6%）
- 误报/噪音：324 次（约 93.4%）
93.4% 的告警都是”噪音”！
这个数字让我陷入了沉思。
作为一个在上海努力搬砖的打工人，我每天要处理的工作已经够多了。结果还要在这些”噪音”里找真正有价值的告警，这不是雪上加霜吗？
不行，必须得优化！
下午：开始排查”噪音”来源
优化告警的第一步，是找出”噪音”的来源。
我仔细分析了一下这 324 次误报，发现主要有以下几类：
第一类：阈值设置不合理
有些告警的阈值设得太低了。
比如某某服务器的 CPU 告警，阈值设的是 60%。但实际上，这个服务器的 CPU 平时就跑在 50-70% 之间，稍微有点负载波动就会触发告警。
你说这算什么问题？这分明就是正常的业务波动嘛！
优化方法：观察历史数据，找到”异常值”和”正常值”的分界线。
第二类：缺少”for”参数
有些告警没有设置”for”参数，意思是”只要一触发就报警”。
但网络嘛，总会有点抖动。可能某次网络延迟稍微高了一点，健康检查就超时了，然后告警就发出了。但实际上，下一次检查就正常了。
你说这算什么问题？这分明就是”虚惊一场”嘛！
优化方法：给告警加上”for”参数，让它”持续多久才触发”。
第三类：告警聚合没配好
有些问题会触发多个告警，但这些告警是”散着发”的，没有聚合在一起。
比如某某服务器同时出现 CPU 高、内存高、磁盘满的情况，结果发了三条告警。三条告警说的其实是同一台服务器的问题。
你说这算什么？明明一个”服务器多指标异常”的告警就能解决的事情！
优化方法：配置告警聚合，把同类告警合并成一条。
晚上：终于找到了”元凶”
经过一下午的分析和优化，我终于找到了”元凶”。
原来问题出在某某服务的健康检查配置上。这个服务的健康检查没有设置”for”参数，也没有配置合理的超时时间。结果网络稍微有点抖动，就会触发超时告警。
我赶紧修改了配置：
- 超时时间从 2 秒改成 5 秒
- 加上”for: 3m”参数（持续 3 分钟才触发）
- 配置了告警聚合
改完之后，告警数量直接下降了 80%！
那一刻，我仿佛看到了希望的曙光。
感悟：告警优化是一场持久战
经过今天的”告警优化大作战”，我深刻地体会到了一个道理：
告警优化不是一劳永逸的事情，而是一场持久战。
为什么这么说呢？
因为告警的”噪音”来源是多种多样的：
- 业务在变，系统的正常波动范围也在变
- 阈值今天合适，可能明天就不合适了
- 旧的问题解决了，新的问题又会出现
所以，告警优化需要持续进行：
- 定期回顾告警数据，识别新的”噪音”
- 根据业务变化，调整告警阈值
- 收集运维人员的反馈，优化他们认为”没用的”告警
写在最后
说起来，今天的工作总结起来就是：
- 早上被告警”袭击”
- 中午开始排查”噪音”
- 下午找到”元凶”
- 晚上完成优化
虽然做的事情不多，但心里还挺有成就感的。
毕竟，告警优化这种工作，做了可能没人夸，但不做肯定会有人骂。与其等别人来投诉，不如自己主动优化。
这大概就是打工人的觉悟吧。
好的监控系统不需要你半夜爬起来，好的告警配置不需要你天天被骚扰。
明天继续优化，争取让告警数量再降一半。
——
作者：小六，一个今天终于让告警系统安静下来的技术博主
在上海努力搬砖的普通打工人