如何在Prometheus中对Gauge指标按小时聚合计算平均值及二次平均

原查询失效的核心原因 #

你最初写的avg({__name__="metricA"}) by (group, service)属于即时向量聚合，仅会拉取查询时刻最新的单条样本值做分组平均，既没有覆盖过去10小时的时间范围，也没有按小时粒度做时间维度的切片分块，自然无法匹配你需要的聚合逻辑。

核心实现逻辑 #

你需要的计算本质是两层聚合：

• 第一层（时间分块聚合）：把过去10小时的时间范围切分为10个独立的1小时自然块，每个块内对所有原始指标样本算平均值，得到一组小时级别的均值序列
• 第二层（分块结果聚合）：对第一层得到的10个小时级均值，不考虑每个块内的原始样本数量多少，统一给每个块相同的权重，再算一次整体平均值，也就是“均值的均值”

这和全局平均的核心差异：全局平均会被样本量多的小时块拉低/拉高权重，而你要的二次平均是按“小时块”而非“原始样本”做统计单元，每个小时块的权重完全相等，不论块内样本数量多少。

可直接使用的PromQL写法 #

1. 全局维度的二次平均（不区分标签分组，把所有时间序列的逐小时均值放在一起算二次平均）：

   avg(
     avg_over_time(metricA[1h])[10h:1h]
   )
   

2. 保留group、service标签维度的分组二次平均（和你最初想分组的逻辑对齐）：

   avg by (group, service) (
     avg_over_time(metricA[1h])[10h:1h]
   )
   

表达式逐段解释 #

• avg_over_time(metricA[1h])：对每组时间序列，计算往前推1小时窗口内所有原始样本的平均值，这就是第一层的单块小时均值
• [10h:1h]：子查询语法，对上面算出来的小时均值结果，按1小时为固定步长，覆盖过去10小时的范围，一共生成10个采样点（正好对应10个小时块的均值）
• 最外层的avg()：对上面得到的10个小时块的均值做整体平均，就是你要的二次聚合结果

效果验证 #

对照你给出的手动计算场景：

• 如果按过去2小时算二次平均，两个小时块的均值分别为7.2、11.04，最终二次平均结果为(7.2+11.04)/2=9.12，和你的手动计算值完全匹配
• 如果是全局2小时原始样本平均，因为两个小时块内的原始样本数不相等（比如第一小时100个样本、第二小时10个样本），全局平均会被样本数多的块加权，最终得到8.1的结果，和二次平均的逻辑结果存在差异，完全符合你描述的场景表现。

常见注意事项 #

• 子查询的步长要和分块粒度完全一致：如果是按小时分块，步长就设1h；如果是按5分钟块统计，就把表达式里的窗口和步长对应改成[5m:5m]，不然会变成滚动滑动窗口的计算结果，不符合固定时间块的预期
• 聚合前提前收敛无关标签：如果你的指标带有resource、warning这类不需要保留的标签，要在第一层计算的时候就通过avg by (需要保留的标签)把无关维度聚合掉，避免最后结果维度太碎、数值偏离预期
• 注意历史数据保留时长：子查询拉取的时间范围不能超过Prometheus本身的指标保留周期，不然会出现部分小时块无数据、拉低最终聚合值的问题
• 生产环境性能优化：如果集群指标规模较大，直接跑子查询会带来较高的计算开销，可以通过Prometheus的记录规则提前把逐小时均值落盘，再基于记录规则的结果做二次聚合，查询性能会更稳定

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