PromQL increase函数结果异常：24小时出站流量查询求助

核心问题分析 #

你遇到的矛盾点在于：sum(increase(metric[24h]))得出的结果远大于实际值，但sum(current) - sum(offset 24h)的结果符合预期。即使你认为24h窗口内没有counter重置，以下几个方向可以帮你定位问题：

1. 时间序列的标签变化或实例变更 #

increase是对每个单独的时间序列计算增量后再求和，而sum(current)-sum(offset)是直接对当前所有序列的总值与24h前的总值做差。如果24h内发生以下情况，两者结果会产生巨大差异：

• 新实例上线：increase会计算新实例从启动到当前的全量流量（只要启动时间在24h窗口内），而sum(offset)中不包含这些新实例的历史值，导致increase的总和额外加上新实例的全量流量。
• 旧实例标签变更：比如实例的pod_id、instance_id等标签变化，导致原时间序列终止、新序列生成。increase会累加旧序列在24h内的增量（从24h前到终止）和新序列从启动到当前的增量，而sum(current)-sum(offset)仅用新序列当前值减去旧序列24h前的值，两者的差值会被大幅高估。

排查方法：

• 对比当前与24h前的序列数量：

  count(system_network_io{service_name="foo", environment="bar", direction="transmit"})
  count(system_network_io{service_name="foo", environment="bar", direction="transmit"} offset 24h)
  

• 查看所有时间序列的标签，确认是否有旧序列消失、新序列出现的情况。

2. 隐性的非零counter重置 #

你提到7天内存在非零重置，即使24h窗口内的时序图看起来正常，也可能存在未被发现的小幅度重置（比如counter从100GB跳降到50GB，而非回到0）。increase函数的逻辑是：当检测到序列值下降时，默认认为是counter重置为0，会计算当前值 + (前一个值 - 0)的增量，导致总结果被严重高估。

排查方法：

• 检查1分钟窗口内的差值是否存在负值（负值代表counter下降）：

  delta(system_network_io{service_name="foo", environment="bar", direction="transmit"}[1m])
  

如果有负值，说明存在非零重置，increase的计算逻辑会错误放大增量。

3. 指标类型未正确标记为Counter #

如果OpenTelemetry导出的system_network_io未被正确标记为counter类型（累计型指标），Mimir可能会将其当作gauge处理。increase是专为counter设计的函数，作用在gauge上时，会累加所有样本间的正值变化，忽略负值，导致结果远大于真实的总增量。

排查方法：

• 检查OpenTelemetry采集配置，确认system_network_io的指标类型为counter；
• 在Grafana中查看该指标的元数据，验证Mimir中存储的类型是否为counter。

4. 查询步长的影响 #

Grafana的查询步长（Step）会影响increase的计算逻辑：如果步长设置过小，increase会对每个步长区间单独计算增量再累加，若数据存在重复采样或间隔不稳定，可能导致增量被重复计算。

排查方法：

• 手动设置步长为指标的采集间隔（比如15s），重新运行sum(increase(...[24h]))，观察结果是否正常。

替代方案（兼顾重置处理与准确性） #

如果暂时无法解决increase的问题，可以使用以下查询替代，既处理序列终止/重置，又保证结果准确：

sum(last_over_time(system_network_io{service_name="foo", environment="bar", direction="transmit"}[24h])) - sum(first_over_time(system_network_io{service_name="foo", environment="bar", direction="transmit"}[24h]))

该查询取24h窗口内每个序列的第一个值和最后一个值，计算差值后求和，结果与sum(current)-sum(offset)一致，但更适合在可变时间窗口的面板中使用。

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