深色模式
告警有效性度量
摘要：告警好不好不能靠感觉。本文用四宫格（真阳性/假阳性/假阴性/真阴性）定义准确率与召回率，给出可采集的度量方法，让调优有依据。
适用环境
- 告警已接 IM/工单，能记录“是否被处理/是否真实”
- 有 Prometheus（记录告警产生次数）或 Grafana
操作步骤
1. 定义四宫格
| 实际有问题 | 实际没问题 | |
|---|---|---|
| 告警触发 | 真阳性(TP) | 假阳性(FP) |
| 未告警 | 假阴性(FN) | 真阴性(TN) |
- 准确率 Precision = TP / (TP+FP)，越高越不吵
- 召回率 Recall = TP / (TP+FN)，越高越不漏
2. 采集告警量
promql
# 过去 7 天各规则触发次数
sum by (alertname) (count_over_time(ALERTS[7d]))
# 仍 firing 的告警（可能卡住）
count by (alertname) (ALERTS)1
2
3
4
2
3
4
3. 让值班标注假阳性
在 OnCall/工单系统里对每条告警打“有效/误报”标签，周期汇总：
bash
# 假设工单系统导出的 CSV 统计
awk -F, 'NR>1 && $3=="false"{fp++} END{print "误报率:", fp/NR}' alerts.csv1
2
2
4. 计算 MTTC
promql
# 平均确认耗时 = 解决时间 - 触发时间
avg(alert_resolved_ts - alert_fired_ts)1
2
2
DANGER
没有标注回路的度量只是数字。必须让值班每周回标误报，否则准确率永远算不准。
验证
bash
# 看当前 firing 告警是否都能解释
amtool alert query
# Grafana 建面板展示 count_over_time(ALERTS[7d])1
2
3
2
3
常见坑
WARNING
- 只盯准确率会走向“删掉所有告警”——要同时看召回率，漏报代价往往更大。
- 新规则上线应先观察 1-2 周再纳入考核，避免冷启动误判。