正常测试数据掩盖的计数器重置
一句话总结
规则文件语法正确，与规则产生正确数字，是两个不同主张。先合并 counter，可能掩盖各进程的重置。只有正常数据的测试，连这种错误规则也会通过。本单元向真正的 PromQL 引擎输入反例，区分两个主张，并让学员亲自修正记录规则与测试文件。
为什么需要它
想象修复支付服务请求率仪表板的那天：评审中 promtool check rules 成功，平时流量曲线也很平滑；但只有某个实例重启的时间段，仪表板请求率会下降。这不是语法错误，而是计算顺序错误，解析器无法发现。聚合后的数字看似合理，告警也很安静，反而更容易让人放心。
测试不是执行一次名称带 test 的命令就结束的仪式，而是明确规定在什么输入下期待哪些标签和值，并拒绝破坏该期待的实现。如果错误实现也亮绿灯，说明测试漏掉了场景。无需等生产中所有故障都发生后才补测试；可以先找到规则容易隐藏的信息，用小型时间序列建模。
工作原理
实验输入包含 route 和 instance 两个标签。/checkout 的 a 每分钟增加 60，b 每分钟增加 600。因此，在足够长的窗口中，a 每秒为 1，b 每秒为 10。/status 则放置两个各自每分钟增加 60 的实例。必须有这条对照路径，测试才能拒绝连 route 也删除的聚合。如果只输入 /checkout，只看数字很难发现标签被错误删除。
正确的 recording rule 先对每条原始时间序列计算 rate，再按 route 求和。对照规则则先记录按 route 合并原始 counter 的时间序列，再对总和应用 rate。在正常输入的第 6 分钟，两条规则都为 /checkout 返回 11。只测试到这里，没有依据判断哪个实现错误。
反例中，a 依次变为 0、60、120、180、0、60、120，而 b 持续增加。即使 a 重置，b 的增量更大，因此二者总和不会下降。能看到原始数据的 rate 会考虑 a 的重置；只收到总和的 rate 却无法恢复这一事实。关键在于：聚合时消失的信息，不会因为之后改了函数名称而回来。
在固定的 1 分钟输入及求值间隔、第 6 分钟求值、5 分钟窗口下，实际 Prometheus 3.14.0 的结果是：正确的 /checkout 请求率为 10.75，错误结果为 10；原始 resets 按 route 的总和为 1，已记录总和的 resets 为 0；/status 仍为 2。一起检查这四个结果，也能拒绝简单返回常数 10.75 或删除路径的修补。
这里的 10.75 并不表示按秒精确统计了事件账本中的所有请求。rate 使用范围内样本与边界外推；改变求值时刻、窗口或输入间隔，结果也可能改变。因此，测试文件不仅写输入值，还要同时写 interval、evaluation_interval、eval_time。忽略时间条件、只记数字，无法解释下一种情况。
阅读测试文件的顺序
先看 rule_files 读取什么。实验助手会把学员各步骤的规则复制到临时目录的 rules.json。扩展名虽是 JSON，但它是 Prometheus 可接受的有效 YAML 表示。然后阅读输入时间序列的标签和值、求值间隔、检查时刻和期望样本。数组顺序可以改变，但删掉必要时间序列或期望样本，就变成了另一个测试。
每个 promql_expr_test 都包含 expr、eval_time、exp_samples。exp_samples 的 labels 标明数字属于谁，value 写期望值。只确认数字相同是不够的；路径标签消失而总和恰好相同，也可能是错误结果。如果把重置测试的正确答案降为 10，错误规则就会通过，但那不是修复实现，而是更改需求。本练习的输入和期望值契约会拒绝这种放宽。
实验不会因为字符串不同而拒绝产生相同结果的表达式。例如，本输入只有 route 与 instance 标签时，sum without(instance) 可能与 sum by(route) 结果相同。但这并不意味着生产输入加入其他标签后，两者仍相同。测试保证的范围，就是测试输入覆盖的范围。
现场会遇到的情况
部署流水线应同时包含语法检查和语义测试。语法检查快速指出错误的函数调用、字段或表达式；语义测试则确认服务约定的标签、值与时间关系。评审不要只附一个正常输入，还要加入重启、路径分离、无请求、数据缺失等会扰动计算的场景。不仅要看变更规则的结果，还要确认原有重要场景仍成立，因为修正数字时也可能破坏原本的路径隔离。
还应有一次故意放入错误实现。本实验中，只保留正常数据的测试和空 tests 数组，确实都让错误聚合规则通过了。工具成功退出，只表示它被要求执行的检查中没有问题，并不保证所有必要检查都执行了。审查“究竟检查了什么”的习惯，同样适用于所有部署门禁。
接下来学习什么
下一课先学习如何读取缺失和告警的时间轴。随后在实验中观察：同一条错误规则在正常测试中通过，却在重置测试中失败。接着修正 rate-rules.yml 的记录规则，以及 reset-tests.yml 中错误的期望值。助手会在学员文件的临时副本上运行真正的 promtool，分别保留语法和语义结果。不会修改主机或生产监控，输入都是教学用合成时间序列。