拆成两条记录规则后网关看板慢一拍，怎样核对规则依赖的执行顺序

同一规则组里的记录规则按顺序执行，依赖项应排在使用者之前。把B放在A前面时，B可能读取A上一轮的值，图表就表现为慢一拍；跨组不能靠配置文本顺序建立这种依赖保证。

画出原始指标到记录指标依赖

为了复用表达式而拆记录规则时，应画出数据依赖：原始raw先得到A，再由A得到B。若拆分后只检查每条表达式语法，无法发现它们使用的求值时间不同。规则名也不能与现有指标冲突，否则数据来源会更难解释。

把相关规则放同组明确排序

固定raw按分钟为10、20、30，实际promtool在第二分钟核对B。同组A在前时B为30，顺序颠倒时B为20。两份规则都能通过语法检查，但求值结果不同；附件执行两种排列，让“配置合法”和“表达式满足依赖”形成直接对照。

同组顺序依赖与查询时的回看机制结合，才会出现合法但落后一轮的结果。排查时可以同时查询raw、A、B三个记录，在同一求值时刻比较，不要分别刷新三个面板后直接判定。若B使用的是较长range函数，还应额外检查窗口含义，避免把平滑效应误认为规则调度错误。

说明跨组和query_offset版本边界

跨规则组的调度还涉及各组间隔、执行耗时和存储可见性，不应承诺按YAML先后同步。若要求同轮依赖，尽量放入同组并明确顺序；复杂链路也要考虑失败与延迟传播。此例只验证固定版本的本地求值，不模拟生产任务调度延迟或远程写入。

适用范围：固定本地promtool版本，不以Python模拟替代PromQL执行，不宣称跨组强顺序。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

下载后执行两份同组规则排列，ordered_b为30、reversed_b为20。raw输入和求值时刻完全相同，唯一被改变的是依赖顺序。要把例子迁入自己的规则库，应先列出A、B的名称与依赖图，避免上游规则因为重命名或移动分组而静默读取上一轮数据；仅跑check rules不能代替这项结果测试。

Python3.8以上与官方Prometheus3.5.0中的promtool。将工具加入PATH，或把PROMTOOL设为它的绝对路径。程序会在临时目录生成真实规则与测试输入，再调用promtool test rules；断言不符时退出失败，不用自造PromQL求值器替代。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对Prometheus网关记录规则依赖，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（同一规则组内规则按顺序、同一求值时间执行；promtool check rules仅证明语法。）；一手依据2（promtool规则测试支持输入序列、求值时刻、预期告警和表达式值，_与stale分别表示缺样与陈旧。）。

继续阅读：延迟明明只有300毫秒却一直报警，怎样对齐网关指标与告警单位；网关副本重启后请求速率突增，PromQL为何要先rate再sum；聚合层日志与可观测性实践：监控多模型 API 调用。