用recording rules预计算高危PromQL指标是换轻量路径而非加速原查询；需基于资源消耗识别高危表达式，规范编写规则，全面切换查询，并合理控制评估节奏。
直接用 recording rules 预计算高危 PromQL 指标，不是给原查询“加速”，而是换一条更轻的路走——把耗时几秒的实时聚合，变成毫秒级查新指标。关键不在“开不开”，而在“怎么换、换什么、换得对不对”。
识别真正高危的 PromQL 表达式
别凭感觉，看实际资源消耗：
-
查 Prometheus 自身指标：观察
prometheus_engine_queries中高耗时查询（duration_seconds > 2s）、高频调用（count_total 增长快）的表达式 -
盯住典型模式：含
rate(...[5m])+ 多维by (job, instance, pod, path)、嵌套聚合如sum by(...) (avg by(...) (...))、带正则匹配（{path=~"/api/.*"}）的查询 -
验证基数风险：执行
count({__name__="http_requests_total"})或count by (job, instance) ({__name__="http_requests_total"})，若结果超 10k，说明原始指标已属高基数，直接 record 可能雪上加霜
写出安全有效的 recording rule
规则本身写错，等于白忙一场。重点守住三处：
-
record 字段只写合法指标名：如
job:http_requests:rate5m✅；不能带标签，不能含{job="api"}❌ -
expr 里完成所有逻辑：标签过滤、聚合、函数都放这里，例如
sum by (job) (rate(http_requests_total{job=~"api|frontend"}[5m])) -
高基数指标必须先降维：原始指标含动态 label（如
user_id="123456"），record 前务必by (job)或by (service)聚合掉不稳定维度，否则新指标序列数可能翻倍爆炸
切换查询到新指标，才算真正生效
这是 90% 效果落空的根源——Grafana 还在查旧表达式，Prometheus 当然不走预计算路径：
-
Grafana 面板里全部替换：把原来
sum by (job) (rate(http_requests_total[5m]))改成job:http_requests:rate5m - 告警规则中同步更新：alert.rules 文件里所有引用该逻辑的地方，统一指向新指标名
-
验证是否真在用：查
prometheus_rule_evaluations_total{rule_group="your-group-name"}是否持续增长；再查job:http_requests:rate5m是否有数据点输出
控制节奏与范围，避免反向拖垮
预计算不是越密越快，而是要匹配真实使用场景：
- interval 别盲目设小：默认 60s 足够，除非业务要求秒级监控；设成 10s 反而增加评估压力，且无实质收益
-
[5m] 窗口要和实际查询一致：如果你的面板/告警一直用
[5m]，record 就必须用[5m]，否则数据语义不一致 -
避免 record 冗余组合：比如已有
job:http_requests:rate5m，就别再定义job_instance:http_requests:rate5m除非真有面板需要它——每多一条规则，就是多一份存储+计算开销
