经过对文档的一些研究以及与其他人的一些对话,我发现了问题 - 以及解决方案。
耳语文件格式的设计方式是,它希望您(或您的应用程序)发布更新的速度不超过storage-schemas.conf
文件中的最小间隔。此文件用于配置您在不同时间间隔分辨率下的数据保留量。
我的storage-schemas.conf
文件设置的最短保留时间为 1 分钟。默认的 StatsD 守护程序(来自 etsy)设计为每 10 秒更新一次 carbon(石墨守护程序)。这是一个问题的原因是:在 60 秒内 StatsD 报告 6 次,每次写入都会覆盖最后一次(在 60 秒的间隔内,因为您的更新速度超过每分钟一次)。这会在您的图表上产生非常奇怪的结果,因为一分钟内的最后 10 秒可能完全停止,并且在此期间报告的活动为 0,这会导致您在那一分钟编写的所有数据都被完全删除。
为了解决这个问题,我不得不重新配置我的storage-schemas.conf
文件以存储数据的最大分辨率为 10 秒,因此来自 StatsD 的每次更新都将保存在 Whisper 数据库中而不会被覆盖。
Etsy 发布了storage-schemas.conf
他们用于安装 carbon 的配置,如下所示:
[stats]
priority = 110
pattern = ^stats\..*
retentions = 10:2160,60:10080,600:262974
这有 10 秒的最短保留时间,并存储 6 小时的价值。但是,由于我的下一个问题,我显着延长了保留期。
当我让这些数据收集几天时,我注意到它仍然看起来不正常(并且正在报告中)。这是由于两个问题。
StatsD(旧版本)仅报告每 10 秒报告周期内的平均每秒事件数。这意味着,如果您在 1 秒内将密钥增加 100 次,在接下来的 9 秒内增加 0 次,则在第 10 秒结束时,statsD 将向石墨报告 10,而不是 100。(100/10 = 10)。这未能报告 10 秒期间的事件总数(显然)。
较新版本的 statsD 解决了这个问题,因为他们引入了stats_counts
存储桶,该存储桶记录每 10 秒期间每个指标的事件总数(因此在前面的示例中报告 10,而不是报告 100)。
升级 StatsD 后,我注意到过去 6 小时的数据看起来很棒,但是当我查看过去 6 小时之后的数据时 - 事情看起来很奇怪,下一个原因是:
当石墨存储数据时,它将数据从高精度保留转移到较低精度保留。这意味着,使用 etsystorage-schemas.conf
示例,在 10 秒精度的 6 小时后,数据被移动到 60 秒(1 分钟)精度。为了将 6 个数据点从 10 秒精度移动到 60 秒精度,石墨对 6 个数据点进行平均。因此,它将取最旧的 6 个数据点的总值,然后除以 6。这给出了 60 秒期间每 10 秒的平均事件数(而不是事件总数,这是我们关心的具体来说)。
这就是石墨的设计方式,在某些情况下它可能有用,但在我们的情况下,这不是我们想要的。为了“解决”这个问题,我将 10 秒的精确保留时间增加到 60 天。超过 60 天,我会存储每分钟和 10 分钟的精度,但它们基本上是无缘无故的,因为这些数据对我们没有那么有用。
我希望这对某人有所帮助,我知道这让我烦恼了几天——而且我知道没有一个庞大的社区为此目的使用这个软件堆栈,所以需要进行一些研究才能真正弄清楚发生了什么以及如何获得我想要的结果。