两类告警
告警分两类：症状类针对用户可感知的结果，例如错误率上升与延迟超标；原因类针对内部前置信号，例如磁盘将满、复制延迟增大。前者直接对应用户体验，后者用来争取处置时间。
哪一类该进电话
值班的关键决策是如何分配注意力：症状类适合进电话，原因类按紧急程度进工单或低等级通知。原因类信号数量庞大且多数无需立即行动，全部升级为电话会造成告警疲劳，真正故障时反而失去响应能力。
基本信息
| 症状类 | 错误率、延迟、可用性等结果指标 |
|---|---|
| 原因类 | 容量、复制状态、健康检查等前置信号 |
| 分页原则 | 结果指标进电话，前置信号进工单 |
| 数量关系 | 原因类数量通常远多于症状类 |
典型使用场景
- 用户视角告警：请求失败率与耗时超标，直接对应投诉
- 容量前置告警：磁盘剩余空间不足，留出清理时间
- 依赖健康告警：主从延迟或连接池耗尽，提前介入
- 资源类观察：CPU 与内存长期趋势，用于容量规划
- 业务结果告警：订单成功率异常，反映业务受损
两类告警示例
两类告警示例
# 症状类（用户视角）：5 分钟错误率超过 5%
sum(rate(http_requests_total{code=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) > 0.05
# 原因类（前置信号）：主从延迟超过 30 秒
mysql_slave_status_seconds_behind_master > 30两类对照
| 维度 | 症状类 | 原因类 |
|---|---|---|
| 关注点 | 用户能否正常使用 | 系统内部是否在恶化 |
| 通知方式 | 电话与短信 | 工单或低等级通知 |
| 数量级 | 少而精 | 多而分散 |
| 处置时机 | 立即 | 按计划安排 |
落地时的做法
- 先确保症状类告警覆盖关键业务路径，再补原因类信号
- 原因类告警要给出可执行动作，无法行动的信号只放看板
- 定期检查症状类告警是否被原因类噪音淹没
只有原因类告警时，故障可能已经影响用户却无人被叫醒；只有症状类告警时，处置窗口会被压缩，两类需要搭配使用。
把资源类前置信号直接做电话告警，多数时候无法立即行动，只会消耗值班精力并降低对真实告警的敏感度。