普罗米修斯速率函数和区间选择

Pel*_*utt 6 prometheus

我正在对prometheus进行一些监控,并试图了解如何正确使用速率函数.

前提是这个; 我有一个计数器,其配置设置为每15秒摄取一个新值.

现在我试图绘制每秒的速率,所以使用速率函数我这样做:

rate(pgbouncer_sent_bytes_total{job="pgbouncer", database="worker"}[1m])
Run Code Online (Sandbox Code Playgroud)

当我解释速率函数时,查询将在每个查询的时间点给出一个滚动率平均值(在1米回看窗口中).点的间隔由所使用的分辨率指定.

下面是prometheus控制台的截图,包括原始数据图和上面使用1m分辨率的速率查询的图.现在,此处生成的费率图表与我在下图中查看原始数据的预期不符.

数据图

有趣的是,根据加载的时间点,生成的图形看起来会有很大不同.只需重新加载相同的图形,随后几次就会完全将外观转移到一个甚至看起来不一致的程度,因为它代表相同的数据.下面的图像是几分钟之后的相同数据集,但是甚至几秒后也会发生相同的数据集.

率重新加载图

有人能否对这里发生的事情有所了解?

Ali*_*ean 15

AFAICT造成奇怪结果的原因是:(1)你的计数器实际上每分钟只增加一次,即使你每15秒收集一次,再加上(2)普罗米修斯的rate()实施,每隔4个计数器增加一次(在你的特定设置中) .

更确切地说,你似乎计算1分钟的速率,每1分钟计算一次,以15秒的分辨率刮擦,每1分钟(平均)增加.

这意味着什么,普罗米修斯基本上将你的1小时间隔切成不相交的 1分钟范围并估计每个范围内的速率.第一个值是点0和3之间的外推增长率,第二个值是点4和点7之间的外推速率,依此类推.因为你的计数器实际上每分钟只增加一次,你可以遇到两种不同的情况:

  1. 你的计数器增加发生在点对3-4,7-8等之间.在这种情况下,普罗米修斯看到增加率为零(因为0点和3点之间没有增加,点4和7等等.这似乎发生在第一张图的前半部分.
  2. 你的计数器增加发生在0-3,4-7之间的某个位置.在这种情况下,普罗米修斯得到每个区间中最后一个点和第一个点之间的差值(你的实际计数器增加),将它除以2点之间的时间差(平均45秒),然后将其推断为1分钟(基本上高估了1倍.(3) - 我在50分钟内观察到增加〜200k,所以平均速度约为67 QPS,而rate()返回接近90 QPS的东西).这是图表后半部分发生的情况.

这也是您的图表在刷新时看起来截然不同的原因.当前实施的论点rate()是它"平均正确".如果你仔细查看整个图表,那么这是真的.</讽刺>

基本上绘制普罗米修斯rate()increase()在时间范围R上以分辨率R 绘制图形将导致混叠,或者过高估计(在您的情况下为1.33倍)或低估(在您的情况下为零)除了平稳增加的计数器之外的任何东西.

您可以通过将表达式替换为:

rate(foo[75s]) / 75  * 60
Run Code Online (Sandbox Code Playgroud)

通过这种方式,您实际上可以获得相隔1分钟的数据点之间的增长率(75秒范围几乎总是返回5个点,因此4个计数器增加)并将外推反转为普罗米修斯所做的75秒.在边缘情况下会有一些噪音(例如,如果你的评估与刮擦时间一致,那么由于刮擦间隔抖动,在一个范围内可能得到6个点而在下一个范围内可能得到4个点)但是你无论如何都要得到它rate().

顺便说一句,您可以通过将图表的分辨率提高到1秒(任何15秒或更低的时间应该清楚地显示)来查看锯齿.

  • 这是对 rate() 函数的基本动态的一个很好的解释 (4认同)
  • 这是一个很好的解释。我还发现 Rate 结果非常不直观。关于为什么 rate 的行为方式和(可悲的是)为什么 Prometheus 不考虑修复它/在此处提供更直观的替代方案有一些冗长的讨论:https://github.com/prometheus/prometheus/issues/3746 (2认同)

bri*_*zil 2

你所说的与数据不符,原始数据大约每分钟只上升一次。你确定你每15秒刮一次吗?

  • 问题是你的刮擦。1 分钟的刮擦间隔加上 1 分钟的范围将非常容易受到比赛的影响。 (2认同)