Prometheus Recording Rules 和 Alerting Rules 怎么选？

Prometheus 支持两种规则类型：Recording Rules 和 Alerting Rules。两者都通过 PromQL 表达式定期评估，但用途完全不同。Recording Rules 用于预计算并持久化查询结果，Alerting Rules 用于监控指标并在满足条件时触发告警。理解两者的区别与联动方式，是写出高质量 Prometheus 规则的前提。

Recording Rules：预计算提升查询性能

Recording Rules 的核心作用是将复杂或高频的 PromQL 表达式预先计算好，把结果存为新的时间序列。这样仪表盘和查询直接读取预计算结果，无需每次实时计算。

为什么需要 Recording Rules

当 Dashboard 每隔几秒刷新一次，而背后是一个涉及大量时间序列聚合的 PromQL 表达式时，每次实时计算会给 Prometheus 带来明显压力。Recording Rules 把这种计算从每次查询时提前到定期评估时，查询变成简单的指标读取，速度大幅提升。

另一个典型场景是跨团队共享指标。基础设施团队可以把基础聚合结果录制成新指标，应用团队直接基于这些录制指标构建自己的查询，避免重复计算。

配置示例

yaml
groups:
  - name: api_recording_rules
    interval: 30s
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

      - record: job:request_errors:rate5m
        expr: sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))

interval: 30s 表示该组规则每 30 秒评估一次。每条规则的 record 字段指定新指标的名称，expr 字段定义计算表达式。评估完成后，job:http_requests:rate5m 和 job:request_errors:rate5m 就像普通指标一样可以被查询和引用。

命名规范

Recording Rules 的命名直接影响可读性和可维护性。推荐遵循 level:metric:operations 的格式：

• level：聚合维度，如 job、instance、cluster
• metric：原始指标名称，如 http_requests、request_errors
• operations：计算方式，如 rate5m、sum、avg

例如 job:http_requests:rate5m 表示按 job 聚合的 HTTP 请求 5 分钟速率。保持一致的命名规范，能让团队快速理解每条录制指标的含义。

Alerting Rules：监控指标触发告警

Alerting Rules 用于定义告警条件。当 PromQL 表达式的结果满足条件时，Prometheus 会生成告警并推送到 Alertmanager，由 Alertmanager 负责分组、抑制、静默和通知路由。

配置示例

yaml
groups:
  - name: api_alerting_rules
    rules:
      - alert: HighErrorRate
        expr: job:request_errors:rate5m / job:http_requests:rate5m > 0.05
        for: 5m
        keep_firing_for: 10m
        labels:
          severity: critical
        annotations:
          summary: "High error rate on {{ $labels.job }}"
          description: "Error rate is {{ $value | humanizePercentage }}"

关键字段说明：

• alert：告警名称，需在同一个 group 内唯一
• expr：PromQL 表达式，结果非零即视为触发。这里引用了前面 Recording Rules 生成的指标
• for：条件持续满足多久后才真正触发告警。比如 for: 5m 意味着错误率连续 5 分钟超过 5% 才告警，避免瞬时抖动导致的误报
• keep_firing_for：告警触发后，即使条件恢复，仍继续保持 firing 状态一段时间，防止告警频繁闪烁
• labels：附加到告警的标签，用于 Alertmanager 的路由和分组
• annotations：告警的描述信息，支持模板变量，在通知中展示

与 Alertmanager 的集成

Prometheus 自身只负责生成告警，通知的分组、去重、路由由 Alertmanager 完成。在 prometheus.yml 中配置 Alertmanager 地址：

yaml
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 'alertmanager:9093'

Alertmanager 根据告警的 labels 决定路由到哪个接收方（邮件、Slack、PagerDuty 等），并支持抑制（inhibit）和静默（silence）策略。

核心区别

特性	Recording Rules	Alerting Rules
目的	预计算查询结果，存为新时间序列	监控指标，满足条件时触发告警
输出	生成新的时间序列数据	生成告警记录，推送至 Alertmanager
存储	结果写入 TSDB	不写入新时间序列
性能影响	减少实时查询压力，提升 Dashboard 速度	规则评估本身有开销，但告警推送开销极小
典型消费者	Dashboard、其他规则、Ad-hoc 查询	Alertmanager、通知渠道
关键参数	record、expr、interval	alert、expr、for、labels、annotations

一个容易忽略的区别：Recording Rules 的结果是持久化的时间序列，可以通过范围查询获取历史数据；Alerting Rules 的告警状态是瞬时的，一旦恢复就不再存在。

两者联动：用 Recording Rules 为 Alerting Rules 服务

这是实际生产中最常见的模式：先用 Recording Rules 预计算复杂指标，再让 Alerting Rules 引用这些预计算结果。

这样做的好处：

• 告警规则的 expr 更简洁易读，降低维护成本
• 预计算结果可复用，同一组录制指标能支撑多个告警规则
• 避免 Alerting Rules 在评估时执行复杂计算，减少评估超时风险
• 录制指标同时可用于 Dashboard 展示，一套计算多处使用

上面的示例中，HighErrorRate 告警规则直接引用了 job:request_errors:rate5m 和 job:http_requests:rate5m 两个录制指标，expr 只需做一次简单除法，清晰且高效。

规则管理实践

规则文件组织

将 Recording Rules 和 Alerting Rules 分文件管理，便于维护：

yaml
# prometheus.yml
rule_files:
  - /etc/prometheus/rules/recording/*.yml
  - /etc/prometheus/rules/alerting/*.yml

同一 group 内的规则按顺序评估，共享相同的评估时间戳。不同 group 之间并行评估。

语法验证

部署前用 promtool 检查规则文件语法：

bash
promtool check rules /etc/prometheus/rules/*.yml

这能捕获缩进错误、无效的 PromQL 表达式、缺少必填字段等常见问题。

评估性能监控

Prometheus 自身暴露了规则评估的指标，关注以下两个：

• prometheus_rule_evaluation_duration_seconds：规则评估耗时
• prometheus_rule_group_last_duration_seconds：规则组评估耗时

如果某个 group 的评估耗时持续超过其 interval，需要考虑拆分 group 或优化表达式。

级联告警设置

为规则文件设置 limit，防止单个 group 产生过多序列或告警拖垮 Prometheus：

yaml
groups:
  - name: api_alerting_rules
    limit: 100
    rules:
      # ...

当序列或告警数量超过 limit 时，该 group 内所有规则产出的数据都会被丢弃，这是一种保护机制，需要在监控中对 limit 触发进行告警。