告警监控概述：为什么需要告警，告警生命周期
做监控的人，最怕什么？怕线上出了事，自己最后一个知道。我见过不少团队，业务跑得好好的，突然一个慢查询把数据库打挂了，大家却还在看报表数据。为什么？因为没有告警。
告警说白了，就是监控系统的“嗓子”。数据采集回来了，指标都算好了，没人看等于白干。你把 CPU 使用率画成漂亮的折线图，然后周末没人盯着屏幕，图再好看也救不了命。告警就是那个半夜把你叫醒的电话，是那个群里的@所有人。
为什么需要告警
你可能觉得：监控面板都上了，自己偶尔看一眼不行吗？
不行。我来跟你说几个场景：
- 人力不可覆盖 —— 半夜三点，服务器扛不住了，你在睡觉。没有告警，等明天上班发现的时候，用户已经流失了大半。
- 信号无法被注意 —— 指标在缓慢爬坡，两小时内从 50% 涨到 95%。人眼很难发现这种渐变，但告警规则能精确捕捉。
- 关联成本太高 —— 一个微服务挂掉，可能引发 20 个其他模块跟着报错。人工排查至少要花 15 分钟，而告警聚合一秒就能告诉你根因。
核心观点：告警的价值不在于“通知”，而在于“缩短故障发现时间”。目标是把 MTTR（平均修复时间）从小时级压缩到分钟级。
我个人习惯，每个新系统上线之前，先问三个问题：
- 系统挂了，谁会第一个知道？是人还是机器？
- 知道了以后，下一步做什么？有没有预案？
- 这个告警会不会吵死人？收敛做了没有？
这三个问题答不上来，告警方案就不够完整。
告警生命周期
告警不是发了就完事了。从产生到闭环，它其实有一个完整的生命周期。我之前带团队时发现，很多人只关注“告警怎么发”，却从来不关心“告警后来怎么样了”。结果就是告警噪声越来越大，到最后大家直接忽略所有通知。
完整的告警生命周一般包含以下阶段：
| 阶段 | 描述 | 关键动作 |
|---|---|---|
| 产生 | 监控系统采集到指标，触发预设规则 | 定义阈值、设置窗口、评估条件 |
| 路由 | 将告警分配给正确的责任人/群组 | 根据标签、严重等级、轮值表分发 |
| 通知 | 通过通道（电话、微信、钉钉、邮件）送达 | 选择通道、设置重复策略、抑制噪声 |
| 处理 | 工程师介入，排查并修复问题 | 确认、认领、定位、修复 |
| 关闭 | 确认故障已恢复，告警状态变回正常 | 自动恢复或手工关闭 |
| 复盘 | 事后分析告警的有效性和改进点 | 分类统计、噪声分析、规则调优 |
你想想看，如果只做“产生”和“通知”，那这个告警系统就是个单向喇叭。管发不管收，管响不管停。最后工程师被吵烦了，直接关掉通知，告警就变成了噪音。
小技巧：在告警路由阶段，建议按照“团队-服务-严重程度”三层维度做标签化。我曾经因为没做路由细分，一个底层库的错误告警把全组人都炸醒了，结果发现只有一个人负责那个库。从那以后，我强制要求每条告警必须携带 oncall 组标签。
告警的核心原则
有些原则，虽然听起来像老生常谈，但每次出问题都能发现有人没遵守：
- 不丢告警 —— 宁可多报一条，不能漏报一条。漏掉的告警就是线上事故的伏笔。
- 减少噪声 —— 不要因为怕漏报就什么都报。收敛、聚合、抑制、静默，工具都给你了，用起来。
- 可操作性 —— 每条告警都要能给工程师一个明确的行动指引。光说“CPU 高”没有用，要说“CPU 持续 5 分钟 > 90%，请检查 /var/log/nginx/error.log 中的异常请求”。
避坑指南：我曾经在一个电商大促前配置了数百条告警规则，结果当晚告警风暴把值班手机打到死机。复盘时发现，大部分告警都是同一类问题的重复触发，而我们的抑制规则根本没开。嗯，后来我学乖了：任何告警规则上线前，必须先在测试环境跑一遍收敛测试。
告警生命周期知识图谱
下面这张图，把整个生命周期和关键参与者串联了起来。你可以把它贴在工位旁边，设计告警方案时对照着走一遍：
你看，整个流程其实是一个闭环。从“产生”到“关闭”，最后还有一个反向箭头指向“复盘与规则优化”。我曾经在某个项目中忽略了复盘这一步，结果相同的告警每两周爆发一次，每次处理方式都一样，却从来没想过优化规则。后来加上周复盘，告警数量直接下降了 40%。
好了，这一章的核心就是：先搞清楚为什么需要告警，再把生命周期理清楚。下一阶段我们就可以开始撸规则了。