为何Grafana中Prometheus increase函数计算计数器增量与实际不符？

为什么increase返回40而非实际的30？ #

核心问题出在Prometheus increase函数的计算逻辑，加上Grafana查询间隔的对齐规则：

1. increase的插值估算逻辑：increase不会直接取查询区间内首尾样本的真实差值，而是会给查询区间的起始、结束时间点估算一个指标值——如果这两个时间点刚好没有采集到样本，就用相邻的样本做线性插值。
   比如，你的查询区间是1分钟（比如09:36:00-09:37:00），但实际计数器从09:36:31才开始增长，区间开头09:36:00的样本是36，区间内第一个带增量的样本是09:36:45（值56），increase会拿这个样本和下一个09:37:15的样本（值66），估算出09:37:00的数值大概是58，这样算出来的增量是58-36=22；而另一个区间09:37:00-09:38:00的增量计算也会因为插值，导致单个区间或总和出现偏差，最终你看到的某个区间的increase结果就变成了40。
2. 查询区间的对齐问题：Grafana最小查询间隔设为1分钟，$__interval会自动对齐到1分钟的整倍数区间，这就导致查询区间没法精准覆盖你实际的增量时间段（09:36:31-09:37:49），反而包含了前后无增量的时间，插值时会把这段时间的“潜在增长”也算进去，结果自然偏大。

怎么拿到准确的事件数量？ #

给你几个可行的方法：

• 用rate乘以时间间隔替代increase：执行查询 rate(vector_component_sent_events_total{component_id=~"sink.*"}[$__interval]) * $__interval。rate算的是每秒平均增长率，乘以时间间隔后得到的增量比increase更稳定，尤其适合查询步长和采集间隔差很多的场景。
• 直接取首尾样本做差值：如果你的计数器不会重置（或者能处理重置），用 last_over_time(vector_component_sent_events_total{component_id=~"sink.*"}[$__interval]) - first_over_time(vector_component_sent_events_total{component_id=~"sink.*"}[$__interval])，直接拿区间内第一个和最后一个样本的真实值相减，完全避开插值误差。
• 缩小查询间隔：如果业务允许，把Grafana的最小查询间隔改成15秒（和采集间隔一致），这样查询区间能精准对齐样本采集点，插值误差会几乎消失。

内容的提问来源于stack exchange，提问作者W Khan