云原生 Prometheus recording rule 怎样处理

云原生环境里，Prometheus recording rule 适合处理两类查询：仪表盘反复刷新、而且每次都要做相同聚合；或者单次查询已经明显消耗资源，临时计算会拖慢图表和排查。它会把 PromQL 的结果按固定评估周期写成新的时间序列，后续直接查询这个结果。我的处理顺序通常是“先判断是否值得预计算，再设计输出指标，最后检查加载和评估状态”，而不是看到查询慢就给每条表达式都加一条规则。

官方地址：https://prometheus.io/docs/

先判断哪些查询值得做成 recording rule

如果一个表达式被多个看板和排障脚本重复使用，或者它需要跨大量时间序列聚合，优先考虑 recording rule。这样做的收益是把昂贵计算从每次查询移动到规则组的固定评估周期。相反，只运行一次的临时分析、维度仍在快速变化的探索查询，不必急着固化，否则会增加存储和规则维护成本。

一个简单的判断方法是先看查询的输入范围和输出基数：输入覆盖很多序列、输出只有少量稳定维度时，预计算通常更有价值；如果输出仍然保留用户 ID、请求参数等高基数标签，记录结果可能只是把查询压力转成存储压力。

规则组和命名要让结果可维护

Prometheus 的规则文件使用 YAML，recording rule 放在规则组中。规则组内的规则按顺序运行，并共享同一个评估时间；因此可以把同一类指标放在一个组里，但不要把互不相关、耗时差异很大的表达式全部塞进同一组。

groups:
  - name: http-service
    interval: 30s
    rules:
      # 先按实例计算请求速率，保留 job 和 instance 维度。
      - record: instance:http_requests:rate5m
        expr: rate(http_requests_total[5m])

      # 再按服务聚合，输出给看板反复使用。
      - record: service:http_requests:rate5m
        expr: sum without (instance) (instance:http_requests:rate5m)

      # 比例指标分别聚合分子和分母，避免直接平均各实例比例。
      - record: service:http_errors_per_requests:ratio_rate5m
        expr: |
          sum without (instance) (rate(http_requests_errors_total[5m]))
          /
          sum without (instance) (rate(http_requests_total[5m]))

命名可以采用“层级:指标:操作”的形式：层级表达输出保留的标签，指标名保持原始含义，操作按从新到旧描述。聚合时明确写出 without 或 by，这样读者能看出哪些标签被保留、哪些标签被移除。比例类数据不要先求各实例比例再取平均，应该分别汇总分子和分母后再相除。

接入 rule_files 前先做确定性检查

规则文件写好后，不需要先重启服务来试错。Prometheus 官方提供 promtool check rules 做语法检查；检查通过后，把文件路径加入主配置的 rule_files。示例命令如下：

# 先检查 YAML 和规则表达式，避免把格式错误带进服务进程。
promtool check rules rules/http-service.rules.yml

# 检查通过后，再让 Prometheus 重新加载配置；具体信号方式按部署形态执行。
kill -HUP 

# 也可以通过部署系统滚动更新配置，避免手工操作成为唯一发布路径。

规则文件被加载后，可以通过 Prometheus 的规则 API 按 type=record 查询 recording rule。若规则没有出现，先检查 rule_files 路径、配置重载结果和规则组文件名；不要马上修改 PromQL，因为“没有加载”和“表达式结果为空”是两种不同问题。

运行期异常要区分加载、延迟和评估压力

规则已经写入文件，不等于结果一定按预期产生。遇到新指标为空或更新时间落后，我会按三个方向处理：

• 规则未加载：先看规则 API 是否能找到对应的组和规则，再检查主配置中的 rule_files。
• 底层数据还没到：分布式抓取或远程写入场景可能存在可见性延迟，可以给规则组设置合适的 query_offset，让评估时间避开尚未完整到达的数据。
• 规则组评估过慢：如果一轮评估没能在下一轮开始前完成，后续评估可能被跳过，产生的记录序列会出现缺口。此时要看规则组耗时、表达式范围和输出序列数量，而不是单纯缩短 interval。

另外，规则组可以设置 recording rule 的序列数量上限。超过上限时，该规则产生的序列会被丢弃，并在评估中记录错误。生产上应把规则文件作为代码管理，发布前检查语法，发布后关注规则评估失败、错过迭代和新增时间序列数量，形成从变更到结果的闭环。

常见问题

recording rule 会保存历史数据吗？

默认不会补齐规则创建以前的历史结果。它从规则开始被评估后才产生新的时间序列；如果确实需要历史数据，应单独评估回填工具的限制和重叠风险。

每条慢查询都应该做成 recording rule 吗？

不应该。优先固化被反复查询、输入范围大且输出维度稳定的表达式；一次性排查和高基数探索查询保留为临时 PromQL 更合适。

为什么规则文件正确但结果仍为空？

先区分规则是否加载、底层指标是否存在、评估时间是否落后以及表达式是否过滤掉了全部序列。按这四层排查，比反复改规则名更快。