网关副本重启后请求速率突增，PromQL为何要先rate再sum

counter先对每个副本计算rate，再汇总，才能保留单序列的重置证据。先把副本加成一条曲线，某副本归零会被另一副本增长掩盖，或被当成整个合计计数器重置，产生错误速率。

识别counter而非gauge

本例A在第三分钟重启归零，B持续增加。要判断重置，必须仍能看见replica这一层序列。sum抹掉副本身份以后，下降到底来自哪一个进程已经无从区分。看板应先检查原始counter是否带稳定实例标签，再检查查询是否在rate之前聚合。

构造单副本重启序列

固定样本由实际promtool3.5.0求值，正确表达式在第五分钟得到约0.291667次每秒，先sum的子查询得到约0.366667。附件保留完整输入与期望断言。子查询的一分钟网格与原始范围选择还涉及边界采样，数字不能脱离给定求值时间直接搬到其他窗口。

定位线上表达式时，可先临时展开成每副本速率，看看是否某一副本恰好在重启后下降，再检查聚合层。副本标签用于保留重置身份，不应被换成每次请求变化的标签。若采集时已经只暴露所有进程的合计counter，查询层无法重新拆出独立的重置，需先修正指标设计。

说明采样和reset不能恢复精确账务

这组数字只是两个合成副本的比较，不是线上重启造成损失的估算。部署时需要同时核对抓取间隔、窗口长度、缺样和实例生命周期；rate适合观察速率，不能独自重建逐请求账本。若图中标签先被采集端丢弃，改一条聚合表达式也不能恢复已经丢失的身份。

适用范围：全部合成时序，指标名demo_gateway_requests_total；不声称是LiteLLM现行原生指标。

配套样本与复核入口

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

run.py会把JSON形式的测试输入交给promtool支持的YAML解析器，因此不需要额外安装PyYAML。重点比较两个表达式的实际断言，数值单位为每秒。复核时保留第五分钟求值时刻和子查询一步一分钟的设置；想比较其他窗口，应重新计算输入点的包含范围，不能只把5m改成1m以后沿用旧期望。

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

python -B run.py

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

一手依据1（rate先于sum以识别单序列重置；absent区分缺失；increase含窗口外推，可能为小数。）；一手依据2（promtool规则测试支持输入序列、求值时刻、预期告警和表达式值，_与stale分别表示缺样与陈旧。）。

继续阅读：请求计数器只加整数，为什么increase算出小数且不能拿来结账；网关监控图突然归零，是没有请求还是抓取已经断了；聚合层日志与可观测性实践：监控多模型 API 调用。