1. VMP 支持自动复用预聚合结果，无需手动修改看板中的 PromQL。本文介绍哪些查询可以复用已有规则，以及哪些变化会导致无法复用。

说明

表达式满足匹配条件，不代表查询一定命中加速，实际结果请以响应头 X-VMP-Query-Acceleration 为准。更多详细说明参见使用 Recording Rule 预聚合加速查询最佳实践。

|**匹配方式** |**什么样的查询可以匹配** |**典型用途** | |---|---|---| |完整表达式匹配 |查询与规则表达式的计算口径一致。 |直接复用完整的预聚合结果。 | |部分表达式匹配 |复杂查询中的某一段表达式与规则一致，外层计算保持不变。 |在原有查询基础上继续进行比较、统计或判断。 | |继续筛选或汇总 |查询仅使用规则中已保留的标签，并继续进行更粗粒度的汇总。 |复用同一条规则支持不同筛选条件和展示粒度。 | 以下示例均基于如下 Recording Rule 表达式： ```Plain Text sum by (cluster, namespace, service, status_code) ( rate(http_requests_total{job="gateway"}[5m]) ) ``` 生成的预聚合指标为： ```Plain Text workload:http_requests:rate5m ``` ## 哪些查询可以复用本例规则 ### 示例一：完整表达式匹配该查询可以直接命中加速，写法存在少量差异时，只要计算口径不变，仍能复用该规则。 **原始查询：** ```Plain Text sum by (cluster, namespace, service, status_code) ( rate(http_requests_total{job="gateway"}[5m]) ) ``` **命中后改写：** ```Plain Text workload:http_requests:rate5m ``` ### 示例二：只匹配复杂查询中的一部分该查询可以命中加速，系统会先替换可复用的部分，再保留外层判断。响应头出现时，仅表示查询中存在已被替换的表达式。 **原始查询：** ```Plain Text sum by (cluster, namespace, service, status_code) ( rate(http_requests_total{job="gateway"}[5m]) ) > 100 ``` **命中后改写：** ```Plain Text workload:http_requests:rate5m > 100 ``` ### 示例三：增加标签筛选，并缩小分组维度若新增筛选条件所使用的标签在规则中已保留，则该查询可复用预聚合结果。若使用未保留的标签，例如 `pod` 或 `instance`，则无法复用。 **原始查询：** ```Plain Text sum by (service) ( rate( http_requests_total{ job="gateway", cluster="prod-a", namespace="payments", status_code=~"5.." }[5m] ) ) ``` **命中后改写：** ```Plain Text sum by (service) ( workload:http_requests:rate5m{ cluster="prod-a", namespace="payments", status_code=~"5.." } ) ``` ### 示例四：汇总为一个总量预聚合结果可以继续汇总为更粗粒度的结果，例如总量。

说明

被聚合的标签不可恢复，无法在后续查询中用于分组。

**原始查询：** ```Plain Text sum( rate( http_requests_total{ job="gateway", cluster="prod-a" }[5m] ) ) ``` **命中后改写：** ```Plain Text sum( workload:http_requests:rate5m{ cluster="prod-a" } ) ``` ### 示例五：子查询内部匹配子查询内部的表达式可命中加速，外层子查询写法无需修改。使用此类查询时，请确保时间范围已覆盖子查询的回看窗口。 **原始查询：** ```Plain Text max_over_time( ( sum by (service) ( rate( http_requests_total{ job="gateway", cluster="prod-a" }[5m] ) ) )[30m:1m] ) ``` **命中后改写：** ```Plain Text max_over_time( ( sum by (service) ( workload:http_requests:rate5m{ cluster="prod-a" } ) )[30m:1m] ) ``` ### 示例六：min、max 和 count 的派生匹配以下示例分别使用 3 条独立规则，每条规则均保留 `cluster` 和 `service` 标签。 #### min 派生匹配当规则已保留所需标签时，`min` 可以继续在预聚合结果上计算。该方式适用于先按较细粒度预计算，再按更大范围查看最小值。 **规则表达式：** ```Plain Text min by (cluster, service) ( worker_queue_depth ) ``` **生成的预聚合指标为：** ```Plain Text workload:worker_queue_depth:min ``` **原始查询：** ```Plain Text min( worker_queue_depth{ cluster="prod-a" } ) ``` **命中后改写** ```Plain Text min( workload:worker_queue_depth:min{ cluster="prod-a" } ) ``` #### max 派生匹配 `max` 的处理方式与 `min` 类似，可以在预聚合结果上继续汇总。只要筛选条件和保留维度一致，即可复用。 **规则表达式：** ```Plain Text max by (cluster, service) ( worker_queue_depth ) ``` **生成的预聚合指标为：** ```Plain Text workload:worker_queue_depth:max ``` **原始查询：** ```Plain Text max( worker_queue_depth{ cluster="prod-a" } ) ``` **命中后改写：** ```Plain Text max( workload:worker_queue_depth:max{ cluster="prod-a" } ) ``` #### count 派生匹配 `count` 与 `min`、`max `不同，继续汇总时通常需要使用 `sum` 累加结果。若直接继续使用 `count`，结果通常不代表原始序列总数。 **规则表达式：** ```Plain Text count by (cluster, service) ( up ) ``` **生成的预聚合指标为：** ```Plain Text workload:up:count ``` **原始查询：** ```Plain Text count( up{ cluster="prod-a" } ) ``` **命中后改写：** ```Plain Text sum( workload:up:count{ cluster="prod-a" } ) ``` ## 哪些变化不能复用本例规则下表以本节开头的请求速率规则为例。无法复用表示该规则不能替换对应表达式，查询仍会按照原始 PromQL 执行。 |**查询变化** |**无法复用的原因** | |---|---| |增加 `pod="pod-a"` 筛选 |规则未保留 pod，无法按该标签筛选。 | |使用 `sum by (pod)` 分组 |pod 维度已被聚合，无法恢复。 | |移除 `job="gateway"` |查询范围扩大，超出规则原有覆盖范围。 | |将 `5m` 改为 `1m` |计算窗口变化，统计口径不同。 | |将 `rate(...) ` 改为 `irate(...)` |计算函数及指标含义发生变化，结果含义不同。 | |将 `sum` 改为 `avg` |规则保存的是求和结果，无法由该结果还原平均值。 | |将 `by (...)` 改为 `without (...)` |输出标签集合变化，无法直接复用。 | |增加 `offset` |查询时间语义变化，与规则表达式不一致。 | 判断查询能否复用规则时，建议依次检查： 1. 原始指标是否一致。 2. 函数和计算窗口是否一致。 3. 基础筛选条件是否保持不变。 4. 新增筛选使用的标签是否已被规则保留。 5. 输出分组是否为规则保留维度的子集。

托管 Prometheus