4. 阈值设定原则：静态阈值 vs 动态阈值、基线概念、阈值设定的黄金法则
阈值设定是告警系统的核心决策点。错误的阈值要么导致告警疲劳（Too Many Alerts），要么导致真实故障被淹没（Silent Failure）。本节从静态与动态阈值的本质差异出发，引入基线概念，并给出避免告警风暴的黄金法则。
4.1 静态阈值 vs 动态阈值
| 对比维度 | 静态阈值 | 动态阈值 |
|---|---|---|
| 定义 | 固定数值或百分比，如 CPU > 90% | 基于历史数据或机器学习自动调整 |
| 适用场景 | 资源上限明确（如磁盘满、内存 OOM） | 业务流量波动大、周期性明显的系统 |
| 优点 | 简单、可预测、调试容易 | 自适应、减少误报、覆盖潮汐流量 |
| 缺点 | 无法适应流量变化，容易误报或漏报 | 依赖历史数据质量，冷启动困难 |
| 维护成本 | 低，一次设定长期有效 | 中高，需要持续校准模型 |
实践建议： 对于基础设施类指标（磁盘、内存、网络丢包）优先使用静态阈值；对于业务类指标（QPS、响应时间、错误率）优先使用动态阈值或基线偏移检测。
4.2 基线概念
基线（Baseline）是系统在“正常”运行状态下的指标分布范围。它不是单一数值，而是一个包含均值、标准差、分位数（P50/P95/P99）的统计模型。
- 时间维度基线： 按天、周、月周期统计。例如：工作日上午10点的QPS基线为 5000 ± 800。
- 事件维度基线： 按版本发布、促销活动、节假日等特殊事件建立独立基线。
- 多维度基线： 结合实例、机房、服务版本等标签，形成细粒度基线。
基线建立步骤：
1. 收集至少 14 天（推荐 30 天）的历史数据，粒度 1 分钟。
2. 剔除已知故障和变更窗口的数据点。
3. 按时间窗口（如每小时）计算均值、标准差、P50/P95/P99。
4. 设定偏移系数：通常以均值 ± 3σ 作为告警触发线。
1. 收集至少 14 天（推荐 30 天）的历史数据，粒度 1 分钟。
2. 剔除已知故障和变更窗口的数据点。
3. 按时间窗口（如每小时）计算均值、标准差、P50/P95/P99。
4. 设定偏移系数：通常以均值 ± 3σ 作为告警触发线。
4.3 阈值设定的黄金法则
避免过度告警与告警风暴的核心在于：分层、分级、降噪、收敛。以下是经过大规模生产环境验证的黄金法则：
- 法则一：告警必须可行动（Actionable）
每个告警必须有明确的响应动作。如果收到告警后只能“观察”，说明阈值太敏感或指标选择错误。 - 法则二：使用多级阈值（Multi-Level Thresholds）
设置 Warning（警告）、Critical（严重）两级，避免直接触发最高级别。 - 法则三：引入持续时间（Duration）
指标持续超过阈值 N 分钟才触发告警，过滤瞬时毛刺。 - 法则四：告警聚合与抑制（Aggregation & Inhibition）
相同故障源的告警合并为一条，避免告警风暴。 - 法则五：定期复盘与调优（Review & Tuning）
每季度至少一次阈值有效性评审，根据实际告警命中率调整。
告警风暴典型诱因：
• 单一故障导致上下游多个服务同时告警（缺乏依赖拓扑抑制）
• 阈值设置过窄，正常波动即触发（缺乏基线容忍度）
• 批量实例同时重启/扩缩容，触发大量同质告警（缺乏聚合）
• 告警通知未分级，所有告警都发到同一个群/电话（缺乏分级）
• 单一故障导致上下游多个服务同时告警（缺乏依赖拓扑抑制）
• 阈值设置过窄，正常波动即触发（缺乏基线容忍度）
• 批量实例同时重启/扩缩容，触发大量同质告警（缺乏聚合）
• 告警通知未分级，所有告警都发到同一个群/电话（缺乏分级）
4.4 阈值调优的量化指标
调优后需要用量化指标衡量效果，避免“感觉变好了”的主观判断：
| 指标名称 | 计算公式 | 目标值 |
|---|---|---|
| 告警命中率 | 真实故障告警数 / 总告警数 × 100% | > 80% |
| 误报率 | 误报告警数 / 总告警数 × 100% | < 20% |
| 漏报率 | 未告警的真实故障数 / 总真实故障数 × 100% | < 5% |
| MTTA（平均确认时间） | 告警触发到首次确认的时间总和 / 告警总数 | < 5 分钟 |
| 告警收敛比 | 聚合前告警数 / 聚合后告警数 | > 10:1 |
调优节奏建议：
• 首次设定：基于基线 + 3σ 设定初始阈值
• 运行 2 周后：统计告警命中率/误报率，调整偏移系数
• 运行 1 个月后：引入持续时间参数，过滤毛刺
• 每季度：全面复盘，更新基线（业务增长或架构变更后需立即更新）
• 首次设定：基于基线 + 3σ 设定初始阈值
• 运行 2 周后：统计告警命中率/误报率，调整偏移系数
• 运行 1 个月后：引入持续时间参数，过滤毛刺
• 每季度：全面复盘，更新基线（业务增长或架构变更后需立即更新）