我应该如何解释这个可视化的普罗米修斯直方图桶热图？

Question

我用grafana将prometheus直方图桶可视化为热图，下面的图片显示了查询和结果图，我应该如何解释它？

​

​

根据我的攻击者的说法，在这段时间内，我总共发送了300个请求，但当我在上面的图表上将这些数字相加时，我永远得不到确切的300，

而且看起来这些数字是随着时间的推移而波动的，我应该如何以一种有意义的方式解释这个图表？

如果我希望这些数字与该时间窗口中每个存储桶中的请求计数完全相同，我应该怎么做？

哦，对于X-Axis模式，我选择了Series，值我选择了Current。

Answer 1

你不能总是从普罗米修斯那里得到一个精确的速率/增量值，这是有真实原因的。其中之一是失败的抓取，也就是说，每隔一段时间，由于服务缓慢、普罗米修斯缓慢或网络问题，抓取会失败或超时。

另一个原因是，收集的样本永远不会完全scrape_interval分开:总是会有几毫秒或几秒钟的延迟。那么(举个极端的例子)如果你只有两个相隔63秒的样本，你怎么能说出过去1分钟内的精确增长？这是两个值之间的差异吗？这个差异是否调整为60秒(即/ 63 * 60)？

尽管如此，普罗米修斯通过只观察严格落在所要求的时间范围内的样本，进一步将自己困在角落里。解释一下:一个理性的人如何计算计数器在过去30分钟内的增量？它们可能现在取所述计数器的值和30分钟前的值并减去它们。即在PromQL项中(必要时调整计数器复位)：

request_duration_bucket - request_duration_bucket offset 30m

相反，普罗米修斯所做的(假设1m的scrape_interval和一个理想的时序，样本间隔完全1m )本质上是这样的：

(request_duration_bucket - request_duration_bucket offset 29m) / 29 * 30

即，它需要29分钟的增加，并将其外推到30。由于自我强加的限制，与手头问题的性质无关。

请注意，这可以很好地处理平滑且连续增加的计数器。例如，如果你有一个每分钟增加500的计数器，那么在29分钟内增加并外推到30是完全正确的。但是对于任何跳跃和配合增加的情况(这是大多数现实生活中的计数器)，如果它发生在实际采样的29分钟内(恰好增加1/29)，它将稍微高估增加的幅度，或者严重低估它(如果增加发生在未包括在采样中的1分钟内)。如果您在覆盖较少样本的范围内计算速率/增量，则情况会更糟。例如，如果您的范围平均只覆盖5个样本，则高估将是20%，即1 / (5 - 1)，并且(每个)您的增量将在5分钟内完全消失。

我发现解决这个限制的唯一方法是(再次假设scrape_interval为1m)反向工程普罗米修斯的推断：

increase(request_duration_bucket[31m]) / 31 * 30

但这需要你意识到你的scrape_interval并进行相应的调整，这是非常脆弱的(如果你改变了你的scrape_interval，你所有的谨慎调整都会下地狱)。

或者，如果您可以在每次重启实例时将增量降为零：

clamp_min(request_duration_bucket - request_duration_bucket offset 30m, 0)

实际上，我有一个针对普罗米修斯的建议补丁，用于添加xrate/xincrease函数，这些函数的行为实际上更符合您的期望(如上所述)，但它看起来不太可能被接受：https://github.com/prometheus/prometheus/issues/3806