在忽略重置的同时处理普罗米修斯计数器答案

【问题标题】：Handling prometheus counters while ignoring resets在忽略重置的同时处理普罗米修斯计数器
【发布时间】：2019-09-27 16:12:12
【问题描述】：

我已经阅读了Prometheus how to handle counters on server 并且我一直在网络上进行挖掘，但我仍然没有找到一种方法来完成我正在尝试做的事情。 Prometheus 可能不是这项工作的最佳工具，我不确定。

每天，我们都会收到 N 个来自客户的请求包。我们已经安装了一个计数器来计算数据包的数量。我可以使用 rate 和 increase，它们会随着时间的推移而变化，并且会有所帮助，但我们对总体计数非常感兴趣，我们希望忽略重新启动。

我希望看到的是一个从 0 开始的图表，随着时间的推移显示看到的响应数量，永不下降，说明重置。

我知道忽略重置的总数本身在某处可用，因为“即时”查询似乎能够返回它。我还没有找到任何可以让我执行此图表的查询变体。

TLDR;我想查看一段时间内的绝对计数

编辑： Alin - 当我在任何时间范围内尝试您的解决方案时，我看到了我之前看到的内容：

即使在低分辨率下——我也不太关心精度——只希望它是 +-100。我只是想看看没有这些峰值/下降的整体趋势。

【问题讨论】：

【解决方案1】：

increase(my_counter[1000y])

但它会很慢。

或者，您可以有一个记录规则，该规则会随着源计数器的增加而永远增加一个计数器。但是您必须记住以下几点：

出于某种深不可测的原因，increase(foo[1m]) 是对前 1 分钟增加的估计值，而不是 foo - foo offset 1m 的改进版本（仅用于处理计数器重置）。
您的规则不会像您告诉 Prometheus 那样经常被评估，并且某些评估可能会被完全跳过。因此，如果在跳过评估（或 Prometheus 关闭）的那一刻发生增加，它将永远消失。

是的，正如许多地方所述，Prometheus 不适合用于会计目的。无论您多么努力，它都不会为您提供准确的值。

【讨论】：

截图回复
正如我所说，increase(foo[1m]) 是对请求期间实际增长的估计。更准确地说，它只采用属于请求的1m 的样本（因此，没有foo offset 1m），然后通过外推来补偿（如Prometheus issue 3806 中的详细描述）。因此，当您的计数器第一次出现然后立即跳到 ~5k 时，这种推断夸大了增长。
您可以通过使用记录规则（并且有可能错过一些增加或重复计算它们）和使用类似 clamp_min(foo - foo offset 1m, 0) 的表达式（假设您的规则评估间隔）来解决该限制是1m），然后绘制sum_over_time(foo:increase[1000y]) 的输出（其中foo:increase 是上面评估的记录规则）。

【解决方案2】：

这可以在 VictoriaMetrics 中使用running_sum 函数完成：

running_sum(increase(foo))

它将显示一个图表，显示foo 在所选时间范围内的增加。图表将从所选时间范围开始时的 0 开始，并在所选时间范围结束时增长到最大值。

如果数据库包含多个匹配foo 选择器的时间序列，则图形将包含多条线。可以通过在查询中添加sum 将其合并为一行：

running_sum(sum(increase(foo)))

该查询还依赖于在方括号中为increase 函数自动添加后视窗口 - 这是MetricsQL feature

【讨论】：