华为云 CES 告警降噪实战：从每天 200 条噪声短信到 7 条有效告警

上周我们的告警群一天能刷出两百多条消息，值班同学已经集体免疫——真正该看的 CPU 打满反而被埋了。这篇记录我们怎么用华为云 CES（云监控服务）把噪声压到每天 7 条以内，且没漏过一次真实故障。

一、先给告警分级，再谈降噪

我们把监控项拆成三层。第一层是基础设施指标：ECS 的 CPU、内存、磁盘使用率，直接挂 CES 原生告警规则；第二层是中间件指标，DCS Redis 的内存命中率和连接数、RDS 的慢 SQL 数量，走各服务自带的监控页签推送到 CES；第三层是业务自定义指标，用 put-metric-data 接口每 60 秒上报一次订单成功率和支付延迟分位数。分层之后才发现，八成噪声来自第一层里一堆阈值拍脑袋的旧规则。

二、用抑制策略砍掉风暴

CES 告警规则的「告警抑制」是最容易被忽略的配置。默认不抑制，一台机器磁盘打满会每分钟触发一条。我们把同类规则的抑制周期统一设为 30 分钟，风暴期间同一对象只发一条。另一个大杀器是无数据点处理：我们把持续集成的构建机这种按需扩容的实例，无数据视为正常，否则每次缩容都告一轮。

三、阈值要带时间窗

CPU 80% 报警是最经典的噪声源。瞬时的 GC 抖动、定时任务都会顶到 80%。最终写法是：CPU 平均值连续 5 个周期（即 5 分钟）大于 85% 才告警，磁盘使用率则相反，用「任意一次大于 90%」——磁盘满没有渐变过程。自定义指标的订单成功率掉了 2% 且持续 3 分钟才告，避免发布瞬间的正常抖动误报。

四、通知渠道分级

告警联系人组按值班表拆成三组：P0 走短信加电话，只挂实例宕机、可用区不可用这类规则；P1 走企业微信机器人，挂阈值类规则；P2 只进邮件和消息通知，供白天复盘。这样即使某个规则又抖了，噪声也被限制在 P2 池子里，不会打扰值班。

五、复盘闭环

每周一把上周所有触发的告警导出来看一遍：触发后无人处理的，要么调阈值要么删规则；处理过的，检查指标名和维度是否够用。两个月下来规则数从 143 条精简到 61 条，每天的有效告警从两百多条降到 7 条以内，并且用这套规则在两次真实故障（一次 Redis 大 key、一次磁盘写满导致容器驱逐）里都提前 10 分钟拿到了通知。

监控不是配完就结束的，阈值和时间窗要跟着业务节奏一直调。降噪的本质是重新定义「什么值得叫醒一个人」。

附：踩过的两个坑

第一个坑是维度爆炸。自定义指标上报时把 instance_id 当成了固定维度，缩容后旧维度还在持续报无数据，配合「无数据告警」就产生了大量幽灵告警。解决办法是把无数据处理的判断周期拉长到 15 分钟，并在上报端加一个 30 分钟的实例存活校验。

第二个坑是恢复通知的缺失。CES 的告警规则默认只发触发通知，不发恢复通知，导致处理完故障还要手动去面板确认指标回落。我们在每个 P0/P1 规则上都单独建了一条恢复规则（比较符反向、抑制周期一致），值班群里第一次出现了「已恢复」，半夜少开了一次电脑。

现在我们的规则总数是 61 条，每周复盘一次，阈值全部带时间窗，通知渠道三级隔离。这套东西没什么技术含量，但确实让告警重新变得「值得看」。