看板频繁执行相同复杂 PromQL 或查询较长时间范围的数据时，重复扫描原始时间序列会增加查询耗时和计算资源消耗。针对这种情况，您可以使用 Recording Rule 预先计算常用聚合结果并开启查询加速，满足加速条件时，VMP 将自动复用预聚合结果，无需修改原有 PromQL 即可缩短查询时间并降低工作区负载。本文介绍如何使用 Recording Rule 预聚合功能。 ## 前提条件 * 工作区是配置 Recording Rule 和开启查询加速的基础环境，请确保在操作前已完成 [创建工作区](https://docs.volcengine.com/docs/6731/1531458?lang=zh)。 * 设计规则时，建议提前了解哪些查询可以自动匹配加速、哪些变化会导致无法复用，以便合理规划计算口径和标签维度。更多详细说明参见 [哪些查询能够自动匹配加速规则](https://docs.volcengine.com/docs/vmp/Which-queries-can-automatically-match-acceleration-rules)。 ## 操作步骤 ### 步骤一：选择需要加速的查询 1. 登录 [VMP 服务控制台](https://console.volcengine.com/observe/prometheus)。 2. 在顶部导航栏，选择目标项目和地域。 3. 单击左侧导航栏的 **工作区**，然后单击目标工作区名称。 4. 在工作区概览页单击左侧导航栏的 **慢查询，** 选择耗时较高、执行次数较多的 PromQL。更多详细说明请参见 [慢查询](https://docs.volcengine.com/docs/6731/2122552)。 ### 步骤二：设计预聚合规则本步骤以查询 Counter 指标 `http_requests_total` 为例，介绍如何设计预聚合规则并开启查询加速。该指标包含 job、cluster、namespace、service、status_code 及实例相关标签。如果需要查看指定集群和命名空间内各服务最近 5m 的平均请求速率，可使用如下 PromQL： ```Plain Text sum by (service) ( rate(http_requests_total{ job="gateway", cluster="prod-a", namespace="payments" }[5m]) ) ``` 设计预聚合规则时，建议保留看板长期使用的筛选和分组维度，例如 `cluster`、`namespace`、`service`、`status_code`，对于仅用于临时排障的 `instance`、`pod` 等实例维度，可按需决定是否聚合。需要注意的是，维度一旦被聚合，后续将无法通过预聚合指标按该维度下钻查询。基于以上分析，本示例可以设计如下 Recording Rule，实现对查询的自动匹配加速。 ```YAML groups: - name: workload_http_requests_acceleration interval: 1m rules: - record: workload:http_requests:rate5m expr: | sum by (cluster, namespace, service, status_code) ( rate(http_requests_total{job="gateway"}[5m]) ) ``` |**配置项** |**说明** | |---|---| |interval |规则执行周期，即预聚合数据的生成频率。周期越短，数据更新越频繁，但资源开销越高；周期越长，资源开销越低，但数据粒度越粗。

注意

执行周期不能小于 5 秒。

| |record |预聚合指标名称。建议按“业务范围＋原指标＋口径”命名并保持唯一，便于看板引用、口径识别和问题排查。 | |expr |预聚合表达式，决定预聚合数据的统计口径。对于 Counter 指标，建议先执行 `rate` 再聚合，其中 `5m` 为速率计算窗口，与 `interval` 含义不同。 | |by (...) |预聚合后需要保留的标签维度，决定后续可筛选与可分组的范围。未保留的维度会被聚合，后续无法再按该维度下钻查询。 | |labels |用于为预聚合结果新增或覆盖标签。本示例未使用此配置，如需配置，建议仅新增管理类标签，避免覆盖已有业务标签，以防影响看板分组及规则匹配的准确性。 | ### 步骤三：创建规则并开启查询加速 1. 登录 [VMP 服务控制台](https://console.volcengine.com/observe/prometheus)。 2. 在顶部导航栏，选择目标项目和地域。 3. 单击左侧导航栏的 **工作区**，然后单击目标工作区名称。 4. 在工作区概览页单击左侧导航栏的 **Recording Rule 管理**。 5. 单击 **新建规则文件**，配置以下参数。 |**配置项** |**说明** | |---|---| |名称 |配置 Recording Rule 规则文件的名称。同一工作区内，规则文件名称须保持唯一。 | |写入目标 |选择预聚合结果的写入工作区。为确保查询能够复用预聚合结果，建议选择当前查询所在的工作区。 | |YAML 配置 |配置 Recording Rule 规则文件的详情。填入 [步骤二](https://docs.volcengine.com/docs/6731/2692726?lang=zh&TagIDs=2%2C143#91QodkYo) 中的规则。 | |允许用于查询加速 |是否为查询配置预聚合功能。开启后，系统将自动查找原始 PromQL 中与规则表达式匹配的部分，并改写为基于预聚合指标的查询。若未满足匹配条件，系统仍执行原始 PromQL。 | 6. 单击 **确定**，完成配置。 7. 查看规则运行状态，并确认预聚合指标已产生数据。

说明

规则运行正常不代表查询一定命中加速，仍需按照结果验证进行确认。

### 步骤四：使用原始 PromQL 查询

说明

首次验证查询加速前，请确认规则已正常运行且准备期已结束，并确保查询时间范围完全落在准备期结束之后。否则可能因时间未覆盖而无法命中加速。若查询包含子查询，还需覆盖子查询的向前回看窗口（例如 30m:1m 会额外读取前 30 分钟的数据）。满足时间覆盖条件后，再检查表达式匹配与查询步长等其他命中条件。

1. 登录 [VMP 服务控制台](https://console.volcengine.com/observe/prometheus)。 2. 在顶部导航栏，选择目标项目和地域。 3. 单击左侧导航栏的 **Explore**，进入 Explore 页面。 4. 在右上角的配置项中，配置以下选项。 |配置项 |说明 | |---|---| |工作区 |选择规则所在的工作区。本次示例中选择 [步骤一](https://docs.volcengine.com/docs/6731/2692726?lang=zh&TagIDs=2%2C143#AoyxcJaW) 中相同的工作区。

查询工作区与预聚合结果写入工作区不一致时，查询无法复用预聚合结果。 | |Min step |范围查询返回数据点的最小时间间隔，默认为 auto。本示例设置为 1m，不得小于规则的 `interval`。 | |查询时间段 |默认为 **过去 30 分钟**。

单击配置项，允许配置指标的查询时间段。 | |数据刷新方式 |支持 **手动刷新** 和 **自动刷新** 方式。首次验证建议使用手动刷新，避免时间范围变化影响结果对比；持续观察时可按需开启自动刷新。 | 5. 执行 [步骤一](https://docs.volcengine.com/docs/6731/2692726?lang=zh&TagIDs=2%2C143#AoyxcJaW) 的原始 PromQL。 6. 满足规则匹配、时间覆盖和查询步长等条件后，系统会自动将查询改写为基于预聚合指标的等效形式，您无需手动替换看板中的 PromQL，例如： ```Plain Text sum by (service) ( workload:http_requests:rate5m{ cluster="prod-a", namespace="payments" } ) ``` 7. 若使用 Grafana，请确认面板最终发出的是范围查询，且实际 `step` 不小于 `1m`；若使用 `$__rate_interval` 或 `$__interval`，还需确认变量展开后的计算窗口与规则口径一致。 ## 结果验证 ### 确认是否命中自动加速请查看范围查询响应头 `X-VMP-Query-Acceleration`。若命中自动加速，该响应头会返回改写后的 PromQL。仅查询到预聚合指标有数据，不能证明原始 PromQL 已命中自动加速。如果查询经过 Grafana 或其他代理，响应头可能不会透传至浏览器，此时请以 VMP 的实际查询响应为准。 ### 对比同一请求开启与关闭加速的结果使用两组范围查询参数进行对照。两次请求的工作区、PromQL、start、end 和 step 必须完全一致，并使用固定时间范围，避免自动刷新导致对比口径变化。 |**参数** |**加速组** |**原始查询对照组** | |---|---|---| |请求路径 |/api/v1/query_range |/api/v1/query_range | |query |步骤一的原始 PromQL |同一条原始 PromQL | |start、end |固定、已覆盖的 2 小时时间段 |相同起止时间 | |step |60s |60s | |disable_query_acceleration |不传 |true | 建议按以下顺序确认加速效果：

说明

不建议根据单次查询耗时判断加速收益，实际提升幅度取决于原始序列规模、聚合后序列规模、查询频率与服务负载等因素。

1. **请求可用性**：两组请求均应返回成功结果，不能仅根据是否出现加速响应头判断查询是否可用。 2. **业务结果一致性**：对比序列数量、业务标签、同一时间点附近的数值，以及是否出现空值或数据缺口，同时确认看板图例与依赖指标名的逻辑不受影响。 3. **时间粒度与对齐**：Recording Rule 按周期生成结果，查询返回点与求值时刻可能不完全一致。对于变化较快的指标，应结合数据到达延迟与规则周期判断差异，无需要求所有数据点完全一致。 4. **耗时改善**：在负载和缓存条件相近的情况下，交替执行多次并比较整体耗时。样本充足时可进一步统计 P50 和 P95。命中加速不代表查询耗时会按固定倍数下降。 5. **规则开销**：持续观察规则执行状态、预聚合序列数量，以及工作区写入量和存储用量，确保查询收益高于新增的预计算成本。

托管 Prometheus