1. 告警规则基础
1.1 告警规则的定义
告警规则（Alerting Rule）是一段可执行的判定逻辑，它持续消费可观测性数据（指标、日志、链路），在条件满足时生成告警事件。在变更窗口场景下，告警规则是连接“变更行为”与“系统状态”的量化契约。
| 维度 | 说明 | 变更窗口示例 |
|---|---|---|
| 数据源 | 规则评估所依赖的时序指标、日志条目或链路采样 | Pod CPU 使用率、错误日志速率、P99 延迟 |
| 条件表达式 | 基于 PromQL / LogQL 等查询语言编写的布尔判定 | avg(rate(http_requests_total{status=~"5.."}[5m])) > 0.05 |
| 评估周期 | 规则被重复执行的固定时间间隔 | 每 10s 评估一次，持续 3 次满足则触发 |
| 严重级别 | 告警的紧急程度，影响通知渠道和升级策略 | P0（页面级）、P1（电话）、P2（IM 群） |
| 持续时间 | 条件必须持续满足的时长，防止毛刺误报 | 持续 1 分钟以上才触发 |
核心原则：告警规则不是“监控脚本”，而是带有状态机、持续时长、分级和抑制逻辑的声明式配置。在变更窗口内，规则应比常规周期更敏感、更短评估间隔。
1.2 告警规则在可观测性中的角色
告警规则在可观测性体系中处于“数据消费层”与“事件响应层”之间的枢纽位置。它从三大支柱（Metrics / Logs / Traces）中提取信号，转化为可行动的通知。
变更窗口中的特殊角色：告警规则在变更窗口内充当“安全门禁”。它不仅要检测异常，还要区分“变更预期内的波动”与“真正的故障”。标准模板通过预置基线偏移量来实现这一区分。
1.3 告警规则的生命周期
一条告警规则从创建到退役，经历六个阶段。理解每个阶段的状态转换，是编写可靠规则的前提。
生命周期阶段详解
- 创建（Created）：定义规则名称、数据源、表达式、评估周期、持续时间和严重级别。在变更窗口模板中，此阶段还会绑定窗口 ID 和预期基线。
- 评估中（Evaluating）：规则按固定周期执行查询，检查条件是否满足。此阶段不产生告警事件，仅记录评估结果。
- 触发中（Pending）：条件首次满足，但尚未达到配置的持续时间。这是防止毛刺误报的关键缓冲期。变更窗口内可缩短此阶段至 10-30 秒。
- 已触发（Firing）：条件持续满足超过持续时间，正式生成告警事件。事件包含标签、注解、时间戳和当前值快照。
- 已解决（Resolved）：条件恢复为不满足状态，规则自动从 Firing 转为 Resolved。变更窗口内应确保解决通知及时送达，避免告警残留。
- 已禁用（Disabled）：手动关闭规则，或变更窗口到期后自动禁用。禁用后不再评估，但保留历史事件记录。
变更窗口中的生命周期陷阱：许多团队在变更窗口结束后忘记禁用或调整告警规则，导致“窗口期敏感规则”长期运行，产生大量误报。标准模板要求在窗口关闭时自动将规则切换回常规模式或直接禁用。
告警规则与变更窗口的映射关系
| 生命周期阶段 | 变更窗口行为 | 模板配置要点 |
|---|---|---|
| 创建 | 窗口开启时自动创建或激活规则 | 绑定窗口 ID、变更类型标签 |
| 评估中 | 缩短评估周期（如 10s → 30s） | 设置 evaluation_interval: 10s |
| 触发中 | 缩短持续时间（如 1m → 15s） | 设置 for: 15s |
| 已触发 | 通知到变更负责人 + 值班组 | 路由标签 window_id 到专用接收器 |
| 已解决 | 自动发送解决通知，标记窗口健康 | 启用 send_resolved: true |
| 已禁用 | 窗口关闭时自动禁用规则 | 使用 API 或生命周期钩子清理 |
最佳实践：将告警规则的生命周期与变更窗口的生命周期绑定。使用配置管理工具（如 Terraform、Ansible）或告警管理 API 在窗口开启/关闭时自动创建/销毁规则，避免人工遗漏。