2. Recording Rules 核心概念
Recording Rules 是 Prometheus 可观测性体系中用于“预计算 + 缓存”的核心机制。理解其五个构成要素——规则名称、表达式、标签、分组、评估间隔——是设计可靠分层架构的前提。下面逐一拆解每个要素的定义、约束与最佳实践。
2.1 规则名称（Rule Name）
规则名称是 Recording Rule 的唯一标识，也是最终写入 TSDB 的指标名。命名必须符合 Prometheus 指标命名规范：
- 合法字符：仅包含
[a-zA-Z0-9_:]，即大小写字母、数字、下划线和冒号。 - 冒号约定：冒号
:是 Recording Rule 的“保留分隔符”，用于区分原始指标与预计算指标。社区惯例：层级:聚合维度:语义。 - 层级前缀：建议使用
rule:、agg:、slo:等前缀标识规则所属分层。
命名示例：
# 原始指标
node_memory_MemTotal_bytes
# 预计算指标（Recording Rule）
rule:node:memory_utilization
agg:namespace:cpu_usage_avg_5m
slo:service:error_budget_remaining2.2 表达式（Expression）
表达式是 PromQL 查询语句，定义如何从原始指标或下层规则计算新指标。表达式必须满足：
- 返回瞬时向量：Recording Rule 只接受返回
instant vector的 PromQL。 - 避免过重计算：复杂聚合应拆分为多层规则，单条规则内避免嵌套过多
avg(rate(...))。 - 使用
rate()/increase()时注意范围向量：范围窗口建议 ≥ 4 × 评估间隔。
| 表达式类型 | 示例 | 适用场景 |
|---|---|---|
| 简单算术 | node_memory_MemFree_bytes / node_memory_MemTotal_bytes |
利用率计算 |
| 聚合运算 | avg by (namespace) (rate(container_cpu_usage_seconds_total[5m])) |
多维度降维 |
| 分位数计算 | histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) |
延迟 SLO 计算 |
2.3 标签（Labels）
标签控制预计算结果的维度。Recording Rule 支持两种标签操作：
- 保留标签：通过
by()子句保留特定标签，其余标签被丢弃。 - 新增/覆盖标签：在规则配置的
labels字段中静态添加或覆盖标签值。
标签管理原则：
• 避免在
• 分层规则中，上层规则应比下层规则保留更少的标签维度，实现“维度收敛”。
• 始终保留
• 避免在
labels 字段中写入动态值（如时间戳、随机数），会导致指标基数爆炸。• 分层规则中，上层规则应比下层规则保留更少的标签维度，实现“维度收敛”。
• 始终保留
job、instance 等关键标识标签，除非明确需要聚合掉。
2.4 分组（Group）
分组是规则文件内的逻辑组织单元，使用 groups: 字段定义。分组影响规则的评估顺序和并发行为：
- 组内顺序执行：同一组内的规则按定义顺序依次评估，前一条规则的结果可被后一条规则引用。
- 组间并发执行：不同组之间可以并行评估，但受限于评估间隔和查询后端负载。
- 分层映射：建议将同一层级的规则放在同一个组内，组名体现层级信息。
分组最佳实践：
• 将“基础层”规则放在
• 组内规则数量控制在 10～20 条，避免单组过长导致评估延迟堆积。
• 依赖关系明确的规则放在同一组，无依赖的规则拆分到不同组以利用并发。
• 将“基础层”规则放在
group_1_baseline，将“聚合层”规则放在 group_2_aggregation。• 组内规则数量控制在 10～20 条，避免单组过长导致评估延迟堆积。
• 依赖关系明确的规则放在同一组，无依赖的规则拆分到不同组以利用并发。
2.5 评估间隔（Evaluation Interval）
评估间隔决定规则多久执行一次 PromQL 计算并写入结果。全局默认值由 evaluation_interval 配置，但每条规则所在的组可以覆盖此值。
| 层级 | 推荐评估间隔 | 理由 |
|---|---|---|
| 基础层（原始指标派生） | 15s – 30s | 需要快速反映基础设施变化 |
| 聚合层（跨维度汇总） | 1m – 5m | 聚合计算开销较大，降低频率可减少 TSDB 写入压力 |
| SLO / 业务层 | 5m – 15m | 业务指标变化缓慢，且通常用于告警与报表 |
评估间隔与表达式窗口的关系：
如果规则评估间隔为 1m，表达式中的范围向量窗口（如
如果规则评估间隔为 1m，表达式中的范围向量窗口（如
[5m]）应至少为评估间隔的 4～5 倍，确保每次评估都有足够的样本点，避免数据空洞。
2.6 核心概念对比总结
| 要素 | 作用 | 常见错误 | 最佳实践 |
|---|---|---|---|
| 规则名称 | 预计算指标的标识符 | 使用原始指标名，不加层级前缀 | 采用 层级:维度:语义 格式 |
| 表达式 | 定义计算逻辑 | 返回范围向量或标量 | 确保返回瞬时向量，复杂计算分层 |
| 标签 | 控制结果维度 | 在 labels 字段写动态值 | 使用 by() 收敛维度，静态标签慎用 |
| 分组 | 组织规则执行顺序 | 所有规则放在一个组 | 按层级拆分，组内 10～20 条规则 |
| 评估间隔 | 控制计算频率 | 所有层级使用相同间隔 | 基础层短间隔，聚合层/业务层长间隔 |
核心要点：Recording Rule 的五个要素不是孤立配置项，而是相互关联的设计决策。规则名称决定可发现性，表达式决定计算成本，标签决定维度粒度，分组决定执行拓扑，评估间隔决定数据新鲜度。在分层架构中，每一层对这五个要素的权衡都不同，后续章节将详细展开各层的具体配置策略。