2. 告警规则设计：阈值告警、同比/环比告警、智能基线告警、多条件组合告警
告警规则是可观测性体系的“触发引擎”。设计不当的规则会导致告警风暴或漏报，直接拉低故障定位效率。本章围绕四种核心告警策略展开，重点说明其适用场景、参数配置与常见陷阱。
2.1 阈值告警（Threshold Alerting）
阈值告警是最基础的告警方式，通过设定固定上下界来判定异常。适用于资源水位、错误率等具有明确容忍边界的指标。
| 参数 | 说明 | 推荐值 |
|---|---|---|
| 指标 | 监控对象，如 CPU 使用率、内存占用 | 按业务定义 |
| 条件 | >、<、>=、<=、== | 通常使用 > 或 < |
| 阈值 | 触发告警的数值边界 | CPU 建议 80% |
| 持续周期 | 连续满足条件的评估周期数 | 2~3 个周期 |
| 静默时间 | 告警恢复后再次触发的最小间隔 | 5~15 分钟 |
实践要点：阈值告警容易因毛刺产生误报。建议配合“持续周期”参数，例如连续 3 个采集周期（共 3 分钟）均超过阈值才触发，可过滤瞬时抖动。
2.2 同比/环比告警（Year-over-Year / Period-over-Period Alerting）
同比/环比告警通过对比当前值与历史同期值来检测异常，适用于具有明显周期性规律的指标，如日活用户、订单量、API 调用频次。
- 同比（YoY）：当前时刻与 7 天前同一时刻对比。适用于周周期业务。
- 环比（PoP）：当前时刻与 24 小时前同一时刻对比。适用于日周期业务。
- 偏差率：（当前值 - 历史值）/ 历史值 × 100%。通常设置 ±20% 为告警线。
常见陷阱：同比/环比告警在业务大促、版本发布等“历史基线失效”场景下极易误报。建议在重大变更期间临时调整偏差率或切换为固定阈值模式。
2.3 智能基线告警（Dynamic Baseline Alerting）
智能基线告警利用机器学习算法自动学习指标的历史规律，生成动态上下界。适用于无固定阈值、波动范围大的指标，如响应时间、GC 暂停时间。
| 算法类型 | 适用场景 | 训练窗口 | 灵敏度 |
|---|---|---|---|
| 移动平均（MA） | 平稳指标 | 7 天 | 低 |
| 指数加权移动平均（EWMA） | 趋势变化较快的指标 | 14 天 | 中 |
| 季节性分解（STL） | 强周期性指标 | 28 天 | 高 |
| Prophet | 多周期叠加、节假日效应 | 60 天 | 可调 |
配置建议：智能基线告警需要至少 14 天的历史数据才能收敛。上线初期建议先观察不告警，待基线稳定后再开启告警动作。同时设置“绝对阈值兜底”，防止基线漂移导致漏报。
2.4 多条件组合告警（Composite Alerting）
多条件组合告警将多个单一告警条件通过 AND / OR / NOT 逻辑组合，形成更精确的触发规则。适用于需要多维度确认的复杂故障场景。
# 示例：组合告警规则（PromQL 风格）
# 条件 A：错误率 > 5%
# 条件 B：P99 延迟 > 2000ms
# 条件 C：CPU 使用率 > 80%
# 组合逻辑：(A AND B) OR (A AND C)
- alert: HighErrorRateWithLatencyOrCPU
expr: |
(rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05)
and
(histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2)
or
(rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05)
and
(node_cpu_seconds_total{mode="idle"} < 0.2)
for: 3m
labels:
severity: critical
annotations:
summary: "高错误率伴随延迟或CPU异常"
组合策略：优先使用 AND 减少误报，使用 OR 扩大覆盖。对于关键业务，建议设置“主条件 AND 辅助条件”的组合，例如“错误率升高 AND 流量无明显下降”才触发，避免因客户端降级导致的误报。
2.5 四种告警策略对比
| 策略 | 适用指标 | 误报率 | 漏报率 | 配置复杂度 | 推荐场景 |
|---|---|---|---|---|---|
| 阈值告警 | CPU、内存、磁盘 | 中 | 低 | 低 | 基础设施监控 |
| 同比/环比告警 | 业务量、调用次数 | 中 | 中 | 低 | 周期性业务监控 |
| 智能基线告警 | 响应时间、GC、错误率 | 低 | 低 | 高 | 动态波动指标 |
| 多条件组合告警 | 复合故障场景 | 低 | 低 | 高 | 核心业务链路 |
2.6 告警规则设计流程
下图展示了从指标采集到告警触发的完整设计链路，帮助理解各策略在体系中的位置。
2.7 告警规则设计检查清单
- 指标选择：是否选择了可量化、可对比的核心指标？避免使用日志级别等非数值指标。
- 阈值合理性：阈值是否基于历史数据统计得出？是否考虑了业务高低峰差异？
- 持续周期：是否设置了足够的持续周期来过滤毛刺？建议至少 2 个周期。
- 静默时间：是否配置了静默时间防止重复告警？建议 5~15 分钟。
- 组合逻辑：多条件组合是否使用了 AND 减少误报？是否设置了 OR 兜底防止漏报？
- 基线更新：智能基线告警的训练窗口是否定期更新？是否设置了绝对阈值兜底？
- 告警分级：是否根据严重程度设置了不同的告警级别（critical / warning / info）？
- 通知路由：告警是否按级别路由到正确的通知渠道（电话、短信、IM、邮件）？
实战建议：在压测环境中，建议先使用“阈值告警 + 多条件组合”作为快速响应手段，待积累足够历史数据后再引入智能基线告警。压测期间临时关闭同比/环比告警，避免因流量突增导致误报干扰分析。