3. 告警策略设计:告警级别定义(P0-P4)、告警阈值设置原则、告警静默与升级机制、告警通知渠道(钉钉、企微、短信、电话)
告警策略设计,说白了就是回答三个问题:什么时候该叫?叫多大声?叫谁?
我见过太多团队,一上来就堆告警规则,结果半夜被P0告警轰炸,一看是某个测试表延迟了5秒。这种“狼来了”式的告警,最后大家直接把通知群屏蔽了。所以,告警策略的核心不是“不漏报”,而是“精准且可行动”。
3.1 告警级别定义:P0到P4的划分逻辑
我个人习惯把CDC告警分成五个级别,从P0到P4。这个分级不是拍脑袋定的,它直接决定了响应时效和通知渠道。
| 级别 | 定义 | 典型场景 | 响应要求 |
|---|---|---|---|
| P0 | 核心链路中断,数据丢失风险 | Binlog解析进程崩溃、Kafka集群不可用、全量+增量断连超过RPO阈值 | 立即响应,7×24值班 |
| P1 | 主要功能受损,数据延迟严重 | 单表同步延迟超过10分钟、连接池耗尽、OOM频繁 | 15分钟内响应 |
| P2 | 部分功能异常,但可降级运行 | 某分片同步失败、DDL解析异常、checkpoint写入失败 | 1小时内响应 |
| P3 | 非功能性告警,需关注 | CPU/内存使用率超过80%、GC频繁、连接数突增 | 下一个工作日处理 |
| P4 | 信息通知,无需立即处理 | 版本升级通知、配置变更记录、日常健康检查报告 | 仅记录,不强制响应 |
核心原则:P0/P1必须能直接指向“数据是否安全”和“业务是否受损”。如果一个告警来了,值班同学需要查三份文档才能判断要不要起床,那这个告警级别定错了。
3.2 告警阈值设置原则:别让阈值成为摆设
阈值设得太松,故障没人管;设得太紧,全是噪音。我总结了三句话:基线驱动、分层设置、动态调整。
3.2.1 基线驱动
不要拍脑袋设“延迟超过60秒告警”。你得先跑一周的监控数据,看看正常情况下的P99延迟是多少。比如正常延迟是2秒,那阈值可以设在10秒(5倍基线)。如果正常延迟就是50秒,阈值设在60秒,那基本天天告警。
我的习惯:用过去7天的P99延迟作为基准线,阈值设为基准线的3-5倍。对于P0级别的延迟告警,我会额外加一个“持续超过阈值N分钟”的条件,避免毛刺导致误报。
3.2.2 分层设置
同一个指标,不同级别用不同阈值。举个例子:
- P3告警:延迟 > 30秒,持续1分钟
- P2告警:延迟 > 5分钟,持续1分钟
- P1告警:延迟 > 15分钟,持续30秒
- P0告警:延迟 > 30分钟,持续10秒(说明数据可能已经丢了)
你看,级别越高,阈值越严苛,持续判定时间反而可以缩短。因为P0场景下,每一秒都可能是数据损失。
3.2.3 动态调整
我曾经踩过一个坑:给某个大促核心表设了固定的延迟阈值,结果大促当天流量暴涨,延迟从2秒飙到2分钟,告警刷屏。后来我改成了动态阈值——根据写入流量QPS自动调整延迟基线。流量高时,基线自动上浮,避免误报;流量低时,基线收紧,敏感发现异常。
注意:动态阈值一定要有“硬上限”。比如再怎么动态,延迟超过30分钟必须P0告警。这是兜底逻辑,不能丢。
3.3 告警静默与升级机制
告警静默和升级,是一对“刹车”和“油门”。没有静默,值班同学会被重复告警烦死;没有升级,故障可能烂在手里。
3.3.1 告警静默
静默不是“关掉告警”,而是在特定条件下抑制重复告警。我常用的静默策略有三种:
- 时间窗口静默:同一个告警规则在N分钟内只发一次。比如延迟告警,5分钟内只发一条,避免刷屏。
- 依赖静默:如果上游组件挂了(比如Kafka集群不可用),下游所有相关告警自动静默。因为这时候报“表A同步延迟”没有意义,根因在上游。
- 维护窗口静默:每周二凌晨2-4点例行维护,这段时间内所有P2以下告警自动静默。P0/P1告警仍然保留,但会打上“维护中”标签。
避坑指南:我曾经遇到过一个问题——静默时间设得太长,导致真正的故障被淹没了。比如延迟告警静默了30分钟,结果这30分钟内延迟持续恶化,直到数据丢失才被发现。所以我的建议是:静默窗口不要超过P0/P1响应时间的1/3。P0要求立即响应,静默窗口最多5分钟。
3.3.2 告警升级
升级机制解决的是“告警发了没人处理”的问题。我设计了一个三级升级链路:
- 第一级:告警发送到值班同学(On-Call),等待确认。如果5分钟内未确认,自动升级。
- 第二级:升级到值班组长,同时发送短信+电话。如果10分钟内未确认,继续升级。
- 第三级:升级到架构师/技术负责人,全渠道轰炸(电话+短信+企微@所有人)。
升级不是惩罚,而是兜底。我见过有些团队把升级搞成了“追责工具”,结果大家都不敢承认收到告警,反而延误了处理。记住:升级的目的是“找到能处理的人”,不是“找到该背锅的人”。
3.4 告警通知渠道:钉钉、企微、短信、电话
不同级别的告警,用不同的渠道。这个原则很简单,但执行起来有很多细节。
| 告警级别 | 通知渠道 | 说明 |
|---|---|---|
| P0 | 电话 + 短信 + 钉钉/企微@所有人 | 必须确保有人醒来处理。电话是最后一道防线。 |
| P1 | 短信 + 钉钉/企微@对应负责人 | 短信保证手机能收到,@负责人保证群内可见。 |
| P2 | 钉钉/企微群消息 | 群内通知,不需要@所有人,避免打扰无关人员。 |
| P3 | 钉钉/企微群消息(不@) | 仅作为信息流,值班同学有空再看。 |
| P4 | 邮件或内部工单系统 | 不需要实时通知,归档即可。 |
个人经验:电话告警一定要做“防骚扰”设计。比如同一个P0告警,电话只打一次,如果确认了就不再打。我曾经见过一个团队,电话告警没做确认回调,结果一个P0告警打了20遍电话,值班同学差点把手机摔了。
另外,钉钉和企微的机器人要配置好“告警详情卡片”。卡片里至少包含:告警级别、指标名称、当前值、阈值、发生时间、影响范围、处理建议。这样值班同学看到消息就能直接判断要不要处理,不用再登录监控系统查一遍。
3.5 告警策略设计全景图
下面这张图,是我在项目中总结的告警策略设计全景。它把级别、阈值、静默、升级、渠道串在了一起。
嗯,这张图其实就概括了告警策略设计的全部流程。你想想看,从指标采集到最终处理闭环,每一步都有对应的策略。少了任何一环,告警系统都会出问题。
最后说一句:告警策略不是一次性设计完就完事的。我建议每季度做一次告警复盘,看看哪些告警是“无效告警”(发了没人处理),哪些是“漏报告警”(故障发生了但没触发)。根据复盘结果,持续调整阈值、静默窗口和升级链路。告警系统,越用越准。