普罗米修斯的增加（）有时会使价值增加一倍：如何避免？

Question

我发现对于某些图表，我从普罗米修斯那里获得双倍值，其中应该只是：

我使用的查询：

increase(signups_count[4m])

刮擦间隔设置为2分钟的recommended maximum。

如果我查询存储的实际数据：

curl -gs 'localhost:9090/api/v1/query?query=(signups_count[1h])'

"values":[
     [1515721365.194, "579"],
     [1515721485.194, "579"],
     [1515721605.194, "580"],
     [1515721725.194, "580"],
     [1515721845.194, "580"],
     [1515721965.194, "580"],
     [1515722085.194, "580"],
     [1515722205.194, "581"],
     [1515722325.194, "581"],
     [1515722445.194, "581"],
     [1515722565.194, "581"]
],

我看到只有两次增加。事实上，如果我查询这些时间，我会看到预期的结果：

curl -gs 'localhost:9090/api/v1/query_range?step=4m&query=increase(signups_count[4m])&start=1515721965.194&end=1515722565.194'

"values": [
     [1515721965.194, "0"],
     [1515722205.194, "1"],
     [1515722445.194, "0"]
],

但Grafana（以及GUI中的Prometheus）倾向于在查询中设置不同的step，对于不熟悉普罗米修斯内部工作的人，我会得到一个非常意外的结果。

curl -gs 'localhost:9090/api/v1/query_range?step=15&query=increase(signups_count[4m])&start=1515721965.194&end=1515722565.194'

... skip ...
 [1515722190.194, "0"],
 [1515722205.194, "1"],
 [1515722220.194, "2"],
 [1515722235.194, "2"],
... skip ...

知道increase()只是a syntactic sugar for a specific use-case of the rate() function，我想这是应该根据情况应该如何工作的。

如何避免这种情况？我如何让Prometheus / Grafana给我看一些，两次两次，大部分时间？除了增加刮擦间隔（这将是我的最后手段）。

我理解普罗米修斯isn't an exact sort of tool，所以如果我不是在任何时候都有一个好的数字，而且大部分时间都可以，我也没关系。

我还缺少什么？

Answer 1

这被称为aliasing，是信号处理中的一个基本问题。您可以通过提高采样率来改善这一点，4米范围有点短，2米范围。尝试10米范围。

例如，在1515722220执行的查询仅查看580@1515722085.194和581@1515722205.194样本。这是2分钟内增加1，超过4分钟的推断是增加2 - 这是预期的。

任何基于指标的监控系统都会有类似的工件，如果您希望100％准确，则需要日志。

Answer 2

increase()将始终（大约）使您的设置实际增加一倍。

原因是（目前已实施）：

1. increase()是（如您所见）rate()的语法糖，即它是由rate()返回的值乘以您指定范围内的秒数。在您的情况下，它是rate() * 240。
2. rate()在计算中使用外推法。在绝大多数情况下，4分钟范围将准确返回2个数据点，几乎相隔2分钟。然后将速率计算为最后一个和第一个之间的差异（即您的情况下的2个点）除以2个点的时间差（在99.99％的情况下大约120秒）乘以您请求的范围（恰好是240秒） ）。因此，如果2点之间的增加为零，则速率为零。如果2点之间的增长为1.0，则计算出的rate()将接近2.0 / 240，因此increase()将为2.0。

这种方法适用于平稳增加的计数器（例如，如果每2分钟有一个或多或少固定数量的注册）。但是，如果计数器很少增加（就像你的注册计数器一样）或尖锐计数器（比如CPU使用率），你会得到奇怪的高估（比如你看到的增加2）。

你基本上可以逆向设计Prometheus＆＃39;通过乘以(requested_range - scrape interval)并除以requested_range来实现并获得（非常接近）实际增长，实质上是追溯普罗米修斯所做的推断。

在你的情况下，这意味着

increase(signups_count[4m]) * (240 - 120) / 240

或者，更简洁，

increase(signups_count[4m]) / 2

它需要你知道范围的长度和刮擦间隔，但它会给你你想要的东西：＆＃34;一个用于一个，两个两个，大多数时间＆＃34; 。有时你会得到1.01而不是1.0，因为刮痕是119秒，而不是120秒，有时，如果你的评价与刮痕紧密对齐，边界上的某些点可能是包括或不包含在数据点计算中，但它仍然是比2.0更好的答案。