Prometheus指标聚合与Recording Rules规则优化实践

Recording Rules解决高基数指标查询性能问题

Prometheus在处理高基数指标或复杂PromQL表达式时,实时查询会给服务器带来沉重计算负担。Recording Rules是Prometheus内置的预计算机制,将频繁执行的查询结果预先计算并保存为新的时间序列,查询时直接读取预计算结果,响应速度提升数十倍。

典型的应用场景是集群级别的资源利用率聚合。假设有100个节点,每个节点运行50个容器,实时计算整个集群CPU利用率的PromQL需要遍历5000个时间序列并进行跨系列聚合,查询耗时可能超过10秒。通过Recording Rule预计算,查询耗时降到毫秒级。

# recording_rules.yml
groups:
  - name: cluster_resource_rules
    interval: 30s
    rules:
      - record: cluster:cpu_utilization:ratio
        expr: |
          sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (cluster)
          /
          sum(rate(node_cpu_seconds_total[5m])) by (cluster)
      
      - record: cluster:memory_usage:ratio
        expr: |
          sum(container_memory_working_set_bytes{container!="",container!="POD"}) by (cluster)
          /
          sum(kube_node_status_allocatable{resource="memory"}) by (cluster)
      
      - record: namespace:cpu_request:ratio
        expr: |
          sum(kube_pod_container_resource_requests{resource="cpu"}) by (namespace)
          /
          sum(kube_node_status_allocatable{resource="cpu"}) by (namespace)

interval参数控制规则执行频率,默认与Prometheus全局scrape_interval一致。对于关键聚合指标,30秒的执行频率能在精度和性能之间取得平衡。record字段定义新时间序列的名称,expr字段是原始PromQL表达式。

规则命名规范与层级设计

Recording Rules的命名直接影响可维护性和可读性。社区推荐采用冒号分隔的层级命名法:level:metric:operations。每一层有明确的语义:

# 命名层级说明
# level: 描述聚合粒度(cluster/namespace/pod/node)
# metric: 原始指标名称缩写
# operations: 聚合操作(ratio/sum/avg/max)

cluster:cpu_utilization:ratio       # 集群级CPU利用率比率
namespace:memory_usage:ratio         # 命名空间级内存使用比率
pod:cpu_usage:sum                    # Pod级CPU用量总和
node:disk_io:avg                    # 节点级磁盘IO平均值

层级命名的好处在于可以配合Prometheus的标签匹配快速定位。查询cluster:前缀的规则得到所有集群级指标,查询namespace:前缀得到命名空间级指标。避免使用过于通用的名称如cpu_total或memory_usage,它们与原始指标名称冲突且无法区分聚合粒度。

多规则组执行顺序与依赖管理

当一个Recording Rule的expr依赖另一个Recording Rule的结果时,需要将它们分到不同的规则组。Prometheus保证同一个规则组内的规则按顺序串行执行,不同规则组之间并行执行。

# 规则组间依赖配置
groups:
  - name: node_level_rules
    interval: 30s
    rules:
      - record: node:cpu_utilization:ratio
        expr: |
          sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (node)
          /
          sum(rate(node_cpu_seconds_total[5m])) by (node)
  
  - name: cluster_level_rules
    interval: 30s
    rules:
      # 依赖 node:cpu_utilization:ratio 的结果
      - record: cluster:cpu_utilization:avg
        expr: avg(node:cpu_utilization:ratio)

cluster_level_rules组依赖node_level_rules组的输出。由于两组并行执行,cluster_level_rules在第一次执行时可能读取到node:cpu_utilization:ratio的空值。解决方案是将interval错开(如node组15秒,cluster组30秒),或确保依赖链路中上游规则组的执行频率不低于下游。

Recording Rules性能监控与故障排查

规则执行本身消耗Prometheus的CPU和内存资源,设计不当的规则组会拖慢整个实例。Prometheus暴露了多个内置指标用于监控规则执行状态:

# 查看规则执行耗时
prometheus_rule_group_last_duration_seconds

# 规则评估总次数和失败次数
prometheus_rule_evaluations_total
prometheus_rule_evaluation_failures_total

# 规则组最后一次评估时间
prometheus_rule_group_last_evaluation_timestamp_seconds

当prometheus_rule_group_last_duration_seconds接近或超过interval值时,说明规则执行跟不上预定频率,需要优化expr表达式或增大interval。常见的高开销原因包括:使用大范围时间窗口(如1h或24h)、对高基数标签做聚合、嵌套多层子查询。

减少开销的策略:用Recording Rules替代告警中的复杂表达式,将大窗口计算拆分为多级规则(如先按5m聚合,再对5m结果做1h聚合),对高基数标签先relabel剔除不需要的维度再聚合。

与Grafana仪表盘联动配置

Recording Rules与Grafana仪表盘配合形成完整的可观测性方案。在Grafana变量中引用Recording Rules预计算的指标,仪表盘加载速度从秒级降到毫秒级。

# Grafana变量查询 - 使用Recording Rule替代实时聚合
# 原始查询(慢):
# sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)

# 优化查询(快):
node:cpu_utilization:ratio{cluster=~"$cluster"}

仪表盘中所有面板都应优先引用Recording Rules生成的指标。对于需要用户交互式调整参数(如时间窗口、聚合粒度)的场景,保留原始查询作为详细视图入口,默认视图全部使用预计算指标。这种分层查询策略在数百个仪表盘的企业级Prometheus集群中,能将查询延迟P99从30秒降到500毫秒以内。