3. 阈值策略入门：静态阈值 vs 动态阈值、固定阈值告警的局限性

阈值是告警规则的“扳机”——它决定了何时将观测数据转化为告警事件。在生产环境中，选择错误的阈值策略会导致两种同样危险的后果：告警风暴（太多无效告警）或告警沉默（真正故障被淹没）。本章从最基础的阈值分类入手，剖析静态与动态阈值的本质差异，并重点揭示固定阈值在真实业务场景中的致命局限。

3.1 阈值策略的两大阵营

根据阈值是否随时间或数据分布自适应变化，可将阈值策略分为两大类：

3.2 固定阈值告警的三大局限性

尽管静态阈值配置简单，但在现代分布式系统中，它暴露出三个难以克服的结构性问题：

3.2.1 局限性一：无法适应时间维度的周期性

绝大多数在线服务具有明显的日周期（白天高流量 vs 凌晨低流量）和周周期（工作日 vs 周末）。固定阈值要么在低谷期过于敏感（产生大量误报），要么在高峰期过于迟钝（漏报真实异常）。

• 低谷误报案例：凌晨 3 点 CPU 从 5% 突增到 30%，触发 25% 阈值告警——实际只是定时任务，无业务影响。
• 高峰漏报案例：晚高峰 P99 延迟从 800ms 升到 1200ms，阈值设为 2000ms——服务已严重劣化，告警却沉默。

3.2.2 局限性二：无法感知业务语义的差异

不同服务、不同接口、不同用户群体的“正常”范围截然不同。固定阈值对所有实体一视同仁，导致：

• 支付服务的 P99 延迟 200ms 可能已是故障，而报表导出服务的 P99 延迟 5s 仍属正常。
• 核心交易链路的错误率 0.1% 需要立即响应，而推荐爬虫的错误率 5% 可能仍在可接受范围。

3.2.3 局限性三：无法追踪指标的趋势漂移

服务会经历版本迭代、架构改造、流量迁移，指标基线会缓慢漂移。固定阈值一旦设定，往往长期无人维护，逐渐失效：

• 版本升级后：新版本优化了缓存，平均延迟从 100ms 降到 50ms，旧阈值 150ms 变得毫无意义。
• 流量增长后：QPS 从 1000 涨到 10000，内存基线从 40% 升到 70%，旧阈值 80% 已逼近极限。

3.3 静态 vs 动态：一张图看懂本质差异

下图直观对比了两种阈值策略在具有日周期特征的指标上的表现：

3.4 何时仍应使用静态阈值？

尽管动态阈值优势明显，但静态阈值在以下场景中仍是不可替代的选择：

• 硬件资源极限保护：磁盘使用率 100%、内存 OOM、CPU 100%——这些是物理上限，不存在“动态”空间。
• 合规与 SLO 红线：SLA 合同中约定的硬性指标（如 P99 延迟 < 1s），必须用固定阈值强制执行。
• 无历史数据的全新服务：服务上线初期，缺乏基线数据，只能先用静态阈值兜底。
• 简单基础设施监控：如端口存活、进程是否存在、证书是否过期——这些是二元状态，无需动态。

3.5 从静态到动态：阈值策略的演进路径

在实际的告警治理项目中，我们推荐分阶段迁移：

1. 第一阶段（静态兜底）：新服务上线时，使用静态阈值快速建立告警覆盖，避免监控盲区。
2. 第二阶段（数据积累）：收集至少 2-4 周的历史数据，分析指标的周期性、趋势性和波动特征。
3. 第三阶段（动态试点）：选择 2-3 个核心业务指标（如 P99 延迟、错误率）切换到动态阈值，与静态阈值并行运行，对比告警质量。
4. 第四阶段（全面推广）：验证动态阈值效果后，逐步替换所有业务指标的静态阈值，保留静态阈值仅用于资源极限和合规场景。