You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

多实例Prometheus Counter跨实例聚合统计问题咨询

核心认知偏差与查询问题定位
  • 对Prometheus Counter的特性理解存在偏差:Counter的“只增不减”是单进程生命周期内的特性,并非永久不重置。一旦发生进程重启、容器重建、实例滚动更新,Counter的计数会从0开始重新累计。你查询到的request_total瞬时值,本质是每个实例从最近一次启动到查询时刻的累计值,而非从服务上线至今的永久累计值。
  • sum(request_total)的计算逻辑本身不具备统计意义:这个查询是将所有实例、所有标签维度下的瞬时Counter原值直接做算术加总,既没有处理时间维度上的Counter增量,也没有兼容Counter重置带来的数值跳变,结果自然不符合预期。
为什么sum by (instance) (request_total)看起来结果正常

这个查询是按实例维度分组,把单实例下所有path、status_code标签对应的Counter值做组内求和,得到的结果刚好对应该实例从最近一次启动到查询时刻的累计请求数,数值范围符合单实例计数递增的预期,但这个值同样不是服务全生命周期的累计总量。

举个实际统计偏差的场景:集群内2个实例,实例A连续运行10天,当前request_total累计值为10000;实例B5分钟前刚完成重启,当前request_total累计值为100。直接对两者的瞬时值做sum得到10100的结果,既没有计入实例B重启前的历史计数,也没有统一的计数起点口径,和真实的全局总请求数自然存在显著偏差。

符合预期的全局求和查询方案

Counter指标的标准使用方式是计算指定时间窗口内的增量,而非直接对瞬时原值做跨维度汇总,根据不同的统计需求对应正确写法:

  • 计算指定时间窗口内全集群新增的总请求数(最常用场景)
    使用sum(increase(request_total[时间范围])),例如要统计过去1小时的全集群无过滤总请求数,查询语句为:
    sum(increase(request_total[1h]))
    该写法的核心优势:
    • increase()函数会自动检测时间窗口内所有Counter的重置行为,将重置前后的数值增量正确拼接,不会因为实例重启导致Counter数值从高点回落被误算为负增量
    • 外层不指定分组标签的sum(),会自动聚合所有实例、所有path、所有status_code维度的增量结果,刚好满足不对标签做任何过滤、取全局总和的需求
  • 估算截至查询时刻的全服务历史累计总请求数
    这个需求无法通过单次瞬时查询精确得到,因为实例重启导致的Counter重置会丢失历史计数,只能通过长期累加各时间窗口的增量实现,通常会结合rate()函数做长期窗口的估算,例如:
    sum(rate(request_total[30d]) * 86400 * 365)

内容的提问来源于stack exchange,提问作者vesna

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.10.25 22:15:03