prometheus - 正确检测 Prometheus 计数指标的变化

Question

我试图编写一个 PromQL 查询来检测计数指标的变化。

我的抓取间隔是 15 秒。

我像这样查询指标:

http_server_requests_seconds_count{outcome!="REDIRECTION",outcome!="SUCCESS"}

它显示了所有 http_server_requests 的数量那不是重定向并且不成功。

我使用此指标编写警报表达式的尝试如下所示:

sum by(service, method, outcome, status, uri) (
  rate(
    http_server_requests_seconds_count{
      outcome!="REDIRECTION",
      outcome!="SUCCESS"
    }[1m]
  )
) * 60

我的想法是 [1m] 乘以 60 秒的速率将是 1当发生变化时，但据我所知我得到 2 ?

这些图表清楚地表明了这一点:



上图是求和表达式，下图是服务器请求计数的变化。当底部图形计数 +1 时，顶部图形应暂时上升到 1以及(但实际上它上升到 2 )。

我究竟做错了什么？我是不是误会了什么？我怎样才能写一个查询，给我值 1当发生变化时？我应该期望能够编写这样的查询吗？

谢谢!

Answer 1

这是因为 Prometheus 优先考虑范围是什么的一致定义而不是准确性。 IE。它总是将范围定义为落在(包括)区间 [now() - range, now()] 内的所有样本。这个定义对于仪表非常有意义:如果你想计算 avg_over_time()在时间范围等于步长的情况下，您希望每个输入样本都包含在恰好一个输出样本的计算中。

但对于计数器而言，情况并非如此。在时间范围等于步长的情况下，一个输入值(即两个连续样本之间的增加)基本上被丢弃。 (更多细节参见 Prometheus 问题 #3746 和 3806。)为了弥补它丢弃的数据，Prometheus 使用外推法来调整计算结果。

这意味着如果(如您的情况)您使用的时间范围是抓取间隔的 2 倍(1m 范围为 30s 抓取间隔)，Prometheus 将(平均)在每个范围内找到 2 个样本，但实际时间范围这 2 个样本所涵盖的范围将在 30s 左右.因此，普罗米修斯将有助于将速率推断为请求的 1m通过加倍的值(value)。因此，结果是 2 而不是预期的 1。您还会注意到，因为丢弃了连续样本之间的某些增加(即使没有样本)，并非所有增加的计数器都显示在 rate() 中。图形。 (即 rate() 中没有跳转对应第三次计数器增加。如果你在不同的时间刷新，不同的增加会出现和消失。Grafana 通过始终将请求的范围与步骤对齐来“解决”后者，因此始终丢失同样增加。)

Prometheus 开发人员建议的解决方案是计算更长持续时间的费率。但所做的只是减少错误(3 倍范围内为 1.5，4 倍范围内为 1.33，5 倍范围内为 1.25，等等)，永远不会摆脱它。普罗米修斯的推断通过平稳增加计数器被隐藏得很好，但像你自己的计数器一样突出，就像一个酸痛的拇指，很少增加。)

这个问题的唯一解决方法(没有修复普罗米修斯，我已经提交了一个 PR 并正在维护 a fork)是对普罗米修斯的 rate() 的实现进行逆向工程。 . IE。假设抓取间隔为 30s类似 rate(foo[1m]) 的表达式应替换为:

rate(foo[90s]) * 60 / 90

或更一般地(注意括号内的表达式需要是时间文字，不能是计算)

rate(foo[intended_range + scrape_interval]) * intended_range / (intended_range + scrape_interval)

这样做的原因是 intended_range + scrape_interval range 将为您提供足够的样本来覆盖超过 intended_range 的增加，这就是你想要的。但是随后您必须撤消 Prometheus 的外推法引入的更改，因此需要进行乘法和除法。这是一个丑陋的黑客，取决于您知道您的抓取间隔并将其硬编码到您的记录规则和/或 Grafana 查询中。

请注意，无论您使用哪种方法，您可能都不会得到恰好为 1 的值。 由于服务、网络和内部 Prometheus 延迟，样本通常不会以毫秒为单位对齐，因此每秒的增长率会略低于或略高于预期值。