误报从哪来
误报大体有三类来源：阈值贴边、观测窗口过短、口径算错。处理顺序也应按这个顺序来：先修口径，再看历史分布定阈值，最后才考虑抑制。顺序颠倒的典型后果是用调大阈值掩盖口径缺陷，真实问题反而被压住，值班对告警的信任也会持续下降。
三类误报与处置
| 来源 | 表现 | 处置 |
|---|---|---|
| 口径错误 | 分母、过滤条件或业务周期算错 | 先核对统计口径，再谈阈值 |
| 阈值贴边 | 正常波动频繁越过阈值 | 用历史分布取合理分位重定阈值 |
| 窗口过短 | 瞬时抖动触发告警 | 拉长 for 与统计窗口过滤瞬时噪声 |
| 抑制滥用 | 依赖关系不明确就抑制 | 只在存在因果依赖时抑制 |
调参顺序
- 口径：分母、过滤条件与业务周期影响先核对，避免用错误基准判断异常
- 分布：用历史数据看典型波动范围，取合理分位作为阈值依据
- 时间窗：拉长 for 与统计窗口，过滤瞬时抖动与单次尖峰
- 分级：把可等待的问题降到 IM，电话只留给需要立刻行动的事
- 复核：调完观察两周再评估，频繁微调会让值班无法形成可靠预期
用历史分布定阈值
用历史分布定阈值
# 过去 30 天服务平均延迟的 99 分位（5 分钟采样，用于定阈值）
quantile_over_time(0.99,
(sum by (service) (rate(http_request_duration_seconds_sum[5m]))
/ sum by (service) (rate(http_request_duration_seconds_count[5m])))[30d:5m])
# 当前 5 分钟均值：与该分位值对比后再决定阈值
sum by (service) (rate(http_request_duration_seconds_sum[5m]))
/ sum by (service) (rate(http_request_duration_seconds_count[5m]))误报治理后要同步更新 runbook：值班拿着旧预案处理新阈值，判断标准会对不上，反而增加处置时间。
调参记录项
| 改了什么 | 规则名、表达式调整与阈值变化 |
|---|---|
| 为什么改 | 依据是哪段历史分布或哪次故障复盘 |
| 影响谁 | 值班组、关联团队与依赖的 runbook |
| 何时复核 | 观察期截止日期与复核责任人 |
复核要点
- 调整后统计告警数量变化，确认噪声下降而不是全部消失
- 确认真实故障仍能触发，避免顺手把灵敏度降到失效
- 观察期覆盖工作日与周末、白天与夜间的不同负载形态