3、告警规则原理：Prometheus告警规则结构
Prometheus 告警规则是容量水位巡检的“触发器”。一条规则定义了：在什么指标条件下、持续多久、触发什么级别的告警。理解规则结构是编写精准巡检策略的基础。
3.1 告警规则核心结构
一条完整的 Prometheus 告警规则由五个字段组成，定义在 groups 下的 rules 列表中：
| 字段 | 必填 | 说明 | 容量巡检示例 |
|---|---|---|---|
| alert | 是 | 告警名称，必须唯一且语义清晰 | NodeDiskUsageHigh |
| expr | 是 | PromQL 表达式，返回非零值即触发 | node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.1 |
| for | 否 | 持续时间，防止瞬时抖动误报 | 5m |
| labels | 否 | 附加标签，用于告警路由、分组、严重级别 | severity: critical |
| annotations | 否 | 描述信息，用于告警通知模板 | summary: "磁盘使用率超过90%" |
关键原则：
expr 是规则的核心，for 是稳定性的保障，labels 和 annotations 是告警可运维性的关键。
3.2 字段深度解析
3.2.1 alert —— 告警名称
命名规范建议采用 大驼峰 + 层级前缀 方式，例如 K8sPodMemoryUsageHigh。避免使用空格或特殊字符，保持与 Prometheus 标签体系兼容。
3.2.2 expr —— PromQL 表达式
表达式返回的 向量值 > 0 时，规则进入评估状态。容量巡检中常用三类表达式模式：
- 阈值比较：
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.05 - 速率预测：
predict_linear(node_filesystem_free_bytes[6h], 24*3600) < 0 - 资源饱和度：
rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0.2
3.2.3 for —— 持续时间
for 字段是告警规则中 防抖机制 的核心。在容量巡检中，建议按场景设置不同时长：
| 场景 | 推荐 for 值 | 原因 |
|---|---|---|
| 磁盘使用率 | 5m | 磁盘变化慢，短时间波动多为采样误差 |
| CPU 饱和度 | 2m | CPU 突发频繁，但持续高负载才需告警 |
| 内存泄漏 | 10m | 内存增长需排除 GC 抖动，观察趋势 |
| Pod 重启 | 1m | 重启事件应快速响应，但避免单次 OOM 误报 |
3.2.4 labels —— 标签与路由
labels 用于告警的 分组、路由和去重。容量巡检中至少应包含：
severity：critical/warning/infoteam：infra/sre/platformtier：storage/compute/network
3.2.5 annotations —— 通知模板
annotations 不参与告警分组，但会注入到告警通知中。建议包含：
summary：一句话概括问题description：详细上下文，可引用模板变量{{ $value }}、{{ $labels.instance }}runbook_url：指向运维手册链接
# 完整告警规则示例
groups:
- name: capacity_watermark
rules:
- alert: NodeDiskUsageHigh
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.1
for: 5m
labels:
severity: critical
team: sre
annotations:
summary: "节点 {{ $labels.instance }} 磁盘使用率超过 90%"
description: "当前可用率 {{ $value | humanizePercentage }}，请立即排查"
runbook_url: "https://wiki.example.com/runbook/disk-full"3.3 规则评估周期
Prometheus 使用 全局评估间隔 来周期性计算所有告警规则。评估周期由启动参数 --eval-interval 控制，默认 1 分钟。
评估周期 vs 采集周期： 采集周期（scrape_interval）决定数据入库频率，评估周期决定规则计算频率。两者通常保持一致，但容量巡检场景建议评估周期 ≤ 采集周期，避免数据空洞导致漏报。
评估流程如下：
- Prometheus 每
eval_interval秒执行一次所有规则。 - 对每条规则，执行
expr查询，获取返回的瞬时向量。 - 如果向量非空（有样本值 > 0），则检查
for字段： - 无
for：立即进入 Firing 状态。 - 有
for：启动计时器，持续满足条件达到for时长后进入 Firing。 - 一旦条件不满足，计时器重置，告警进入 Pending → Resolved 流程。
3.4 评估周期对容量巡检的影响
评估周期的选择直接影响告警的 时效性 和 系统开销：
| 评估间隔 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 15s | 秒级响应，适合突发容量事件 | Prometheus 负载高，规则多时可能超时 | 核心服务内存/CPU 快速耗尽 |
| 1m | 默认值，平衡负载与时效 | 对慢速指标（磁盘）足够，对快速指标偏慢 | 大多数容量水位场景 |
| 5m | 极低负载，适合长期趋势 | 告警延迟可达 5-10 分钟 | 存储空间、日志增长等慢变指标 |
避坑提示： 不要将
for 设置为小于 2 倍评估周期的值。例如评估周期 1 分钟，for: 30s 会导致规则在两次评估之间无法稳定判断，容易产生 Pending → Firing 的反复抖动。