告警概述
聊告警之前，我先问一个问题：你上次被半夜电话吵醒，是因为什么？
我猜十有八九是告警。说实话，告警这东西，干运维的没人不熟。但真正把它当回事、做闭环的人，真不多。
什么是告警
告警，说白了就是系统在告诉你：“我撑不住了，快来看看。”它不是一个简单的通知，而是一个信号——某个指标越界了，某个服务挂了，或者某条链路断了。我个人习惯把告警分成三类：
- 阈值类告警：比如CPU使用率持续5分钟超过90%，触发告警。最常见，也最容易产生风暴。
- 异常事件告警：比如某个进程突然退出、磁盘只读、内存泄漏等。这类告警往往意味着已经出问题了。
- 趋势预测告警：比如根据过去一小时的增长率，预计磁盘2小时后写满。这种告警价值最高，因为它给了你缓冲时间。
我曾经接手过一个项目，监控配置了上千条规则，每天告警上万条。结果呢？团队直接屏蔽了通知，因为“反正处理不完”。你想想看，这已经失去了告警的本意。真正的告警，应该是“精准、有效、可行动”的。
告警的核心要素
任何一条有效的告警，都包含几个关键字段。我整理了一个表格，方便你对照自己系统的告警格式：
| 字段 | 含义 | 典型值 |
|---|---|---|
| 告警标题 | 一句话描述问题 | CPU使用率超过90% |
| 告警级别 | P0～P4，标定紧急程度 | P1（严重） |
| 触发时间 | 精确到秒的事件发生时间 | 2025-02-18 14:23:05 |
| 告警源 | 哪个系统或设备产生的 | host01 / database / app02 |
| 指标值 | 实际值与阈值的对比 | 当前92%，阈值90% |
| 关联标签 | 用于分组、路由、排班 | env=prod,team=dba |
嗯，这里要注意：很多团队只配了标题和级别，忽略关联标签。结果告警来了也不知道该找谁处理。我建议你把团队、服务、环境都打上标签，后面做自动化路由就方便多了。
告警的重要性
你可能会想：告警不就是通知吗？有必要专门花一章来讲？
我记得刚入行的时候，也是这样想的。直到有一次线上事故，数据库磁盘写满，但告警因为优先级配置错误被埋在了P4里，没人看到。等我们发现时，业务已经停了20分钟。那次事故的直接原因不是磁盘满，而是告警没有被正确处置。
告警的重要性，可以归纳为三点：
- 发现问题的第一道防线：用户投诉之前，告警必须先到。跑得赢用户，就能赢得修复时间。
- 影响范围的快速判断：一条P0告警配上拓扑标签，你立刻知道这条告警影响多少用户、多少服务。不用等排查。
- 驱动流程闭环的引擎：告警不是终点，是起点。没有告警，你都不知道该修复什么。有了告警，你才能启动“排查→定位→修复→验证→关闭”这一套闭环。
我曾经见过一个团队，把所有告警都设成P0，结果值班同学疲于奔命，最后选择全部ignore。这是典型的“虚假紧迫感”。告警级别一定要根据真实影响来定，能隔夜处理的不要设P0。
说白了，告警是运维的“眼睛”。眼睛花了，你连路都看不清。那闭环操作是什么呢？就是看到告警后，你要做的每一步动作都能被记录、被追踪、被复盘，而不是看一眼就完事。
我习惯把告警闭环画成一张图，你一看就懂：
很多团队做到了“告警产生→处置修复”这一步，就结束了，缺少“验证关闭”。结果修复后过几天发现根本没生效，告警又复现。我一般会在验证阶段加一个自动化的健康检查脚本来确认，确保闭环真正“合上”。
告警的重要性，还体现在它能为事后复盘提供依据。每一次告警的记录，都是你改进监控、优化代码、完善流程的一手资料。没有告警数据，你连哪里容易出问题都不知道。
举个例子，上个月我处理了一个P2告警，发现某个微服务的错误率在下午3点准时飙升。查日志发现是定时任务触发了资源抢占。如果不是告警帮我标记了时间规律，光靠手动翻日志我得翻到什么时候？
所以，别把告警当成“噪音”。它是你的伙伴，不是敌人。学会读懂告警、重视告警、做好闭环，你的值班体验会好很多。