为何Prometheus与Grafana中Counter指标图表出现数值异常波动？

核心原因分析 #

• Counter重置导致的数值断层
  Counter类型指标的核心特性是单调递增，但当暴露该指标的进程重启时，Counter会被重置为0（或进程启动时的初始值）。如果你的图表时间范围覆盖了进程重启的时间点，就会出现旧进程的高值突然掉到新进程的初始累加值，看起来像是数值递减，但这是正常的进程重置行为，并非Counter本身递减。

• 采样步长与时间对齐问题
  图表模式下，Prometheus会根据你选择的时间范围自动计算采样步长（step），按固定间隔抓取样本点。如果某个采样点刚好落在进程重启后的初期，抓取到的是新进程刚启动不久的Counter值，而前一个采样点是旧进程关闭前的高值，就会形成“前高后低”的异常视觉效果。而表格模式显示的是最新的样本值，也就是新进程已经累加了一段时间后的数值，所以和图表中的中间采样点存在差异。

• 直接查询原始Counter的局限性
  直接查询原始Counter值本身没有实际业务意义——Counter的价值在于体现指标的增长速率，而非绝对数值。rate()或increase()这类函数会自动检测并处理Counter重置的情况，计算单位时间内的增量，从而呈现正常的增长趋势。

验证与解决建议 #

• 检查目标服务的进程日志，确认是否存在重启记录，这是最直接的验证方式。
• 立即改用rate(http_requests_total[5m])或increase(http_requests_total[10m])查询，这类函数会自动抹平重置带来的数值断层，展示真实的请求增长速率。
• 可以用http_requests_total offset 1m对比一分钟前的Counter数值，如果差值为负，则说明期间发生了Counter重置。

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