为何Prometheus中sum(avg_over_time)结果高于sum的峰值？

核心原因是两个查询的计算顺序完全相反，再加上不同实例的请求峰值不在同一时刻，最终导致前者结果超过后者的最大值：

1. 拆解两个查询的计算逻辑 #

• 黄线（直接求和）：sum(gin_in_flight_requests{app="my-service",cluster="prod", url="/api/v1/url1"})
  这个查询是在每个采样时刻，把所有符合标签的实例的当前在飞请求数直接相加，得到该时刻的总在飞请求数。你看到的黄线最大值，就是所有采样时刻里这个总和的最高值。

• 绿线（先平均再求和）：sum(avg_over_time(gin_in_flight_requests{app="my-service",cluster="prod", url="/api/v1/url1"}[1m]))
  这个查询分两步执行：

  1. 对每个单独的实例，计算它在1分钟窗口内的在飞请求数平均值；
  2. 把所有实例的这个平均值加起来，得到最终结果。

2. 关键差异：峰值的时间分布 #

当不同实例的请求高峰出现在不同时间段时，就会出现绿线超过黄线最大值的情况。举个直白的例子：
假设你有3个实例：

• 实例A：1分钟里有一半时间在处理10个请求，另一半时间是0 → 平均值是5
• 实例B：1分钟里有60%的时间在处理10个请求，剩下时间是0 → 平均值是6
• 实例C：1分钟里有70%的时间在处理10个请求，剩下时间是0 → 平均值是7

这时候：

• 黄线的实时求和最大值：同一时刻最多只有一个实例在处理请求，所以最大值是10（比如A在高峰时，B和C都是0，总和10；同理B、C高峰时总和也都是10）
• 绿线的结果：5+6+7=18，远高于黄线的最大值10

3. 额外的可能影响：采样对齐问题 #

如果Prometheus的采样间隔和1分钟窗口的对齐存在偏差，或者某个实例的短时间峰值刚好落在两个采样点之间，avg_over_time的计算可能会因为窗口内的采样点分布，让平均值的总和出现波动，但这种情况的影响远小于上面的核心原因。

内容的提问来源于stack exchange，提问作者David Michael Gang