告警系统基础：告警的定义与分类、告警生命周期、告警级别定义、告警通知方式
各位好，我是老赵。今天咱们聊聊告警系统的基础。说实话，很多团队把告警想简单了——不就是出问题发个消息吗？但实际运维过大规模边缘节点的人都知道，告警系统设计得好不好，直接决定了你晚上能不能睡个安稳觉。
我见过太多案例：告警风暴把值班人员淹没了，真正重要的故障反而被忽略。或者告警级别定义混乱，P0 和 P3 混在一起，大家都麻木了。所以这一章，咱们把地基打牢。
告警的定义与分类
先说说什么是告警。我的理解很简单：告警是系统状态偏离预期时，主动触发的通知事件。它不是一个日志条目，也不是一个指标点，而是一个有明确语义的事件。
在边缘计算场景下，告警来源特别杂。我把它分成几类：
| 分类维度 | 类型 | 典型例子 |
|---|---|---|
| 按来源 | 基础设施告警 | CPU 过载、磁盘写满、网络丢包 |
| 应用告警 | 服务进程挂掉、API 响应超时 | |
| 业务告警 | 订单处理延迟、视频流卡顿率超标 | |
| 按触发方式 | 阈值告警 | 内存使用率 > 90% 持续 5 分钟 |
| 变化率告警 | 连接数 5 分钟内飙升 300% | |
| 预测告警 | 根据趋势预测磁盘 2 小时后写满 | |
| 按状态 | 瞬时告警 | 一次性的心跳丢失 |
| 持续告警 | 磁盘故障持续超过 30 分钟 |
我的经验：边缘节点经常断网，所以「瞬时告警」和「持续告警」一定要分开处理。我曾经遇到过一个项目，因为网络抖动，所有边缘节点同时上报了上千条瞬时告警，直接把告警中心打崩了。后来我们加了一个 30 秒的去抖窗口，问题才解决。
告警生命周期
告警不是生下来就完事了。它有自己的生命周期，从产生到消亡，每个阶段都需要明确的状态管理。我习惯用这张图来跟团队讲清楚：
每个阶段的意义：
- 产生 (Firing)：告警条件满足，系统生成告警记录。此时还没人处理。
- 确认 (Acknowledged)：值班人员看到并接手了。这一步很重要，能避免多人同时处理同一个问题。
- 处理中 (In Progress)：正在排查和修复。我建议在这个阶段更新告警的「处理备注」，方便交接班。
- 已解决 (Resolved)：问题修复，告警条件不再满足。但记录还保留着。
- 已关闭 (Closed)：确认无误，归档。通常需要人工或自动验证。
- 自动恢复 (Auto-Recovery)：边缘节点自己恢复了，比如网络重连后心跳恢复。这种告警可以直接关闭，但建议保留日志。
避坑指南：我曾经遇到过一个边缘节点，因为温度过高触发告警，但 5 分钟后温度降下来自动恢复了。结果告警系统直接把它标记为「已关闭」，没有通知任何人。后来这个节点反复高温，反复自动恢复，持续了一周才被发现——散热风扇早就坏了。所以，自动恢复的告警一定要有「重复告警计数」和「升级机制」。
告警级别定义
级别定义是告警系统的灵魂。定得太粗，大家分不清轻重；定得太细，又记不住。我个人习惯用四级制，跟业界主流保持一致：
| 级别 | 名称 | 响应时间 | 典型场景 |
|---|---|---|---|
| P0 | 紧急 (Critical) | 立即响应，15 分钟内 | 节点离线、核心服务不可用、数据丢失 |
| P1 | 严重 (Major) | 30 分钟内 | 磁盘即将写满、CPU 持续 100%、API 错误率飙升 |
| P2 | 警告 (Warning) | 4 小时内 | 内存使用率超过 80%、网络延迟升高、证书即将过期 |
| P3 | 提示 (Info) | 下一个工作日 | 配置变更、版本升级通知、非关键指标波动 |
这里有个关键点：级别不是一成不变的。比如一个 P2 告警持续了 2 小时还没恢复，就应该自动升级到 P1。这叫「告警升级机制」。我见过不少团队把级别定死，结果 P2 告警挂了三天都没人管。
我的建议：在边缘节点上，P0 告警一定要有「双通道确认」。比如同时发短信和打电话，或者通过两个不同的通知渠道。因为边缘节点环境复杂，单一渠道可能失效。我记得有一次，某个节点的 4G 模块坏了，短信发不出去，幸好我们同时配置了 MQTT 通道，才没漏掉。
告警通知方式
通知方式的选择，说白了就是「在正确的时间，用正确的方式，把正确的信息，发给正确的人」。我按紧急程度排了个优先级：
- 电话/语音呼叫：只用于 P0。自动语音播报告警摘要。我建议配合「确认机制」——接听后按 1 确认收到，否则继续升级。
- 短信：P0 和 P1。内容要精简，包含节点 ID、告警类型、时间戳。别写长篇大论，没人看。
- 即时消息 (IM)：所有级别。比如钉钉、企业、Slack。适合带详细信息和处理链接。
- 邮件：P2 和 P3。适合非紧急的汇总报告和趋势分析。
- 告警看板/大屏：所有级别。适合值班室和运维中心，实时展示。
通知内容也有讲究。我见过最差的告警消息就一句话：「节点异常」。这跟没发一样。好的告警消息应该包含：
- 节点唯一标识（ID 或名称）
- 告警类型和级别
- 触发时间和当前值
- 阈值和持续时长
- 处理建议或相关文档链接
一个小技巧：在边缘节点上，我习惯把告警通知做成「分级静默」模式。比如凌晨 2 点到 6 点，P2 以下的告警只记录不通知，P1 只发 IM 不打电话，P0 照常。这样既不影响休息，又不会漏掉关键故障。
好了，告警系统的基础就这些。定义清楚分类、生命周期、级别和通知方式，你的告警系统就已经成功了一半。下一块内容，咱们聊聊告警规则怎么设计——那才是真正考验功力的地方。