华为云 CES 监控告警实战：从"告警轰炸"到"精准告警"的三步法

凌晨三点被警报电话叫醒，爬起来一看却是个无关紧要的指标——这种"告警疲劳"，有时比没有告警更危险。

一、告警轰炸，正在杀死告警本身

很多团队接上云监控后的第一件事，就是"能监控的都配上告警"。结果 CPU、内存、磁盘、网络、QPS……密密麻麻几十条规则，一天几百条通知。值班同学很快学会"看到就忽略"，真正的故障反而淹没在噪音里。

告警的目标从来不是"发出通知"，而是让对的人在第一时间处理对的问题。所以告警体系设计的核心只有两个字：少而准。

二、第一步：选对指标

华为云 CES（云监控服务）的指标大致分两类：

• 基础监控：云服务自动上报，如 ECS 的 CPU 使用率、磁盘读写、网络流量，开箱即用；
• 操作系统监控：需要安装 Agent 才能采集，如内存使用率、磁盘分区、进程数等。

一个常见误区是只盯 CPU。实际上"内存使用率持续爬升"“磁盘 inode 耗尽”"连接数打满"往往比 CPU 更早预示故障。选指标时要覆盖资源、容量、错误率、延迟四个维度，而不是一股脑全选。

三、第二步：阈值要分级，不要一刀切

阈值设置最忌拍脑袋。合理做法是：

• 分级告警：CPU 70% 触发"提示"、85% 触发"重要"、95% 触发"紧急"，不同级别走不同通知渠道；
• 持续周期：设置"连续 N 个周期超过阈值"才触发，过滤瞬时毛刺，避免一次抖动就报警；
• 动态基线：对有明显波峰波谷的业务（白天高、夜里低），用动态阈值比固定阈值更贴合实际。

四、第三步：通知收敛，别让所有人被打扰

告警通知最容易失控。CES 的通知组（Notification Group）可以按服务、按责任人划分，让"数据库告警发给 DBA、应用告警发给开发"，杜绝全员被轰炸。

再叠加告警收敛：同一资源在短时间内重复触发的告警合并成一条，故障恢复后补发恢复通知，避免"一条故障刷屏几十次"。

五、让告警形成闭环

告警发出只是开始。更好的做法是把它接入处置动作：通过 SMN 主题将告警推送到函数工作流（FunctionGraph）或自动化脚本，实现"磁盘满 → 自动清理临时文件""实例异常 → 自动重启或替换"这类自愈。让机器先处理能处理的，人只处理真正需要判断的。

六、实战避坑清单

1. 别监控一切：只为"影响用户或业务"的指标建告警，其余放进看板观察即可。
2. 必须有恢复通知：只有告警没有恢复，值班同学永远不知道问题到底结束了没有。
3. 通知渠道分级：紧急走电话/短信，重要走企业微信，提示只进邮件或工单。
4. 定期复盘误报：误报的规则要么调阈值，要么直接删掉，别让噪音长期存续。
5. 告警要有归属人：没有明确责任人的告警，等于没人处理。
6. 验证告警链路：定期人为触发一次测试告警，确保通知真的能送达，而不是配完就当万事大吉。

七、小结

好的告警体系不是"配得多"，而是"配得准"：指标覆盖关键维度、阈值分级并考虑持续性、通知按责任人收敛、告警能驱动处置。当你把告警从"刷屏"变成"信号"，值班才会从煎熬变成从容。少一条噪音，多一分可靠。