请求计数器只加整数，为什么increase算出小数且不能拿来结账

increase会依据采样窗口进行外推，所以计数器每次加整数，查询仍可能得到小数。它适合观察窗口内的趋势与估计变化，不应该代替逐事件记录参与结算。

先区分counter采样与事件账本

计数器展示的是抓取时的累计快照，抓取之间发生了哪些事件并没有逐条保存在该指标里。窗口左右边界常常不与采样点重合，引擎只能根据已有点与规则外推。将小数强制取整只改变显示方式，不能补回缺少的事件时间信息。

用固定窗口重现外推

附件给出100、101、102三个一分钟间隔采样点，第三分钟缺样；在指定五分钟窗口求值，真实promtool得到3.5。旁边的合成事件表只有两次加一，事件计数为2。两者输入信息不同，放在一张结果里是为了说明用途差别，不是宣称监控系统错误多计了1.5次调用。

需要精确按窗口计数时，事件表至少要有明确时间与去重身份，查询采用怎样的起止包含规则也要说明。counter快照可以用于监控对账线索，但缺失一个采样区间时不能唯一还原事件发生在哪一分钟。本文事件表故意单独保留，提醒读者不要将估计变化与逐条事实混为一份数据。

核心表达式（完整建表与输入见附件）：

increase(demo_gateway_requests_total[5m])

把趋势监控与结算用途分开

换求值时刻、窗口长度、缺样位置或初始计数，会改变外推结果，因此复核必须保留完整时间轴，不能只复制几个数值。收费、退款与争议追溯应依靠可去重的事件账本和明确时间边界；监控曲线可以帮助发现异常，但不能独自证明某租户应支付多少。

适用范围：示例数字按实际promtool运行固定，绝不编造非整数结果；不用于真实结算或费用争议。

配套样本与复核入口

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

执行材料得到increase为3.5、event_count为2，程序内嵌了具体采样序列和事件分钟位置，读者无需访问任何线上指标。要复算外推，先画清窗口起点、最后有效样本与求值时刻，再看缺样处。调整抓取频率后应重新求值；直接把3.5取整成4或舍成3，都不能变成这两次事件的可靠账本。

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

python -B run.py

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

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

继续阅读：同一秒有两条调用，网关用量累计表为何一次跳过两行；网关副本重启后请求速率突增，PromQL为何要先rate再sum；网关用量和上游账单对不上，怎样做一份逐请求对账样本。