告警不是越多越好。一个好告警应该让值班同学快速知道：出了什么事、影响是什么、先看哪里、什么时候升级。
指标要有业务含义
技术指标常见有：
- CPU。
- 内存。
- 磁盘。
- QPS。
- 响应时间。
- 错误率。
- 消息积压。
- 数据库连接数。
但告警文案不能只写“CPU 超过阈值”。它还应该说明这个指标对应哪个服务、可能影响什么业务。
阈值要能解释
阈值不是拍脑袋。
设置阈值时要看：
- 历史基线。
- 峰值流量。
- 业务容忍度。
- 是否有突发毛刺。
- 是否需要持续几分钟才触发。
如果阈值过低，告警会疲劳；阈值过高，又可能错过故障。
告警里要放排查入口
告警信息最好包含：
- 服务名。
- 环境。
- 指标名。
- 当前值。
- 阈值。
- 影响说明。
- 日志入口。
- 监控面板。
- 常见处理步骤。
值班时最怕看到一条孤零零的告警，还要自己到处找面板。
升级路径要明确
不是所有告警都需要半夜叫醒所有人。
可以按等级处理：
- P3：观察和次日处理。
- P2：影响局部功能，需要跟进。
- P1：影响核心链路，需要立即处理。
- P0：大面积故障，需要升级和广播。
等级清楚，响应才不会失控。
维护建议
每条重要告警都应该配一段说明：指标含义、触发条件、排查入口、处理步骤和升级规则。
告警本身是工具，背后的解释文档才是值班效率的关键。
正文完
