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

Question

我使用grafana将普罗米修斯直方图桶可视化为热图，下图显示了查询和结果图，我应该如何解释呢？

根据我的攻击者，在此期间，我总共发送了精确的300个请求，但是当我将这些数字加到上面的图表上时，我永远不会得到确切的300个请求，

并且看起来这些数字随着时间的流逝而波动，我该如何以有意义的方式解释这张图？

如果我希望这些数字成为确切的请求计数，那么该时间窗口中的每个存储桶中都包含该数字，我该怎么办？

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

Answer 1

真正的原因导致您无法始终从Prometheus中获得准确的汇率/增值。其中一种是刮擦失败，即由于服务速度慢，Prometheus慢或网络问题，刮擦有时会失败或超时。

另一个原因是，所采集的样本永远不会完全scrape_interval分开：到处总是有几毫秒或几秒钟的延迟。因此（举一个极端的例子），如果您只有2个采样间隔为63秒，那么如何分辨过去1分钟的精确增长？这两个值之间有区别吗？差异是否调整为60秒（即/ 63 * 60）？

话虽如此，普罗米修斯只看严格落在要求时间范围内的样本，便将自己置于困境。自我解释：一个合理的人如何计算最近30分钟内计数器的增加量？他们可能会立即采用上述计数器的值和30分钟前的值并将其减去。即以PromQL术语（必要时调整计数器重置）：

request_duration_bucket - request_duration_bucket offset 30m

Prometheus所做的工作（假设scrape_interval中的1m和理想的时间序列，样本之间的间隔恰好为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分钟内完全消失1分钟。

我发现解决此限制的唯一方法是（再次假设scrape_interval中的1m）逆向工程Prometheus的推断：

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

但这需要您意识到scrape_interval并对其进行调整，并且非常脆弱（如果您更改scrape_interval，则所有细微的调整都会下地狱。）

或者，如果您确定每次实例重新启动时增量都降为零，则可以：

clamp_min(request_duration_bucket - request_duration_bucket offset 30m, 0)

我确实对Prometheus提出了一个补丁，以添加xrate / xincrease函数，这些函数实际上表现得比您期望的要好（并且如上所述），但看起来不太可能被接受：https://github.com/prometheus/prometheus/issues/3806