使用StatsD（通过etsy）和Graphite跟踪指标，石墨图似乎并没有绘制所有的数据
我们有一个度量标准，每当用户在我们的网站上执行特定操作时，我们都会增加这个度量标准，但是这些图表似乎并不准确。
因此，在这个预感的基础上，我们投入了碳的更新logging，发现今天发生了4000多次的动作（使用grep和wc），但是根据图的积分结果，它只返回了220次。
这可能是什么原因？ 使用statsd php库将数据报告给statsd，并调用statsd::increment('metric'); 如上所述，日志证实今天发生了对该密钥的4000多个更新。
我们正在使用：
石墨0.9.6与statsD（etsy）
上面发表我的评论后，我发现Graphite 0.9.9有一个（新的）configuration文件storage-aggregation.conf，其中一个可以控制每个模式的聚合方法。 可用的选项是平均值，总和，最小值，最大值和最后值。
http://readthedocs.org/docs/graphite/en/latest/config-carbon.html#storage-aggregation-conf
通过文档的一些研究，并与其他人的一些对话，我发现了这个问题 – 和解决scheme。
whisper文件格式的devise方式，它期望你（或你的应用程序）发布更新不会比storage-schemas.conf文件中的最小时间间隔更快。 此文件用于configuration您在不同的时间间隔分辨率下具有多less数据保留。
我的storage-schemas.conf文件被设置为最小保留时间为1分钟。 默认的StatsD守护进程（来自etsy）被devise为每10秒更新一次碳（石墨守护进程）。 造成这个问题的原因是：在60秒内，StatsD报告了6次，每次写入覆盖最后一次（在60秒内，因为你每分钟更新一次）。 这会在您的图表上产生非常奇怪的结果，因为一分钟内的最后10秒可能完全死亡，并在此期间报告活动为0，从而导致您在那一刻写下的所有数据都完全无效。
为了解决这个问题，我不得不重新configuration我的storage-schemas.conf文件，以10秒的最大分辨率存储数据，因此StatsD的每次更新都将被保存在whisper数据库中，而不会被覆盖。
Etsy发布了他们用来安装碳的storage-schemas.confconfiguration，看起来像这样：
[stats] priority = 110 pattern = ^stats\..* retentions = 10:2160,60:10080,600:262974
这有一个10秒的最短保留时间，并存储6小时的价值。 但是，由于我的下一个问题，我大大延长了保留期限。
当我让这些数据收集了几天，我注意到它仍然看起来（正在报告中）。 这是由于2个问题。
-
StatsD（旧版本）仅报告每10秒钟报告周期的平均每秒事件数量。 这意味着，如果你在1秒内增加一次键100次，在接下来的9秒内增加0次，那么在第10秒钟结束时将向石墨报告10，而不是100.（100/10 = 10）。 这没有报告10秒的事件总数（显然）。
较新版本的statsD修复了这个问题，因为他们引入了
stats_counts存储桶，它logging每个10秒期间每个指标的事件总数（所以不是前面的例子报告10，而是报告100）。在升级StatsD之后，我注意到过去6小时的数据看起来不错，但是当我超过了最近6个小时的时候 – 看起来很奇怪，下一个原因是：
-
由于石墨储存数据，它将数据从高精度保留转移到较低的精度保留。 这意味着，使用etsy
storage-schemas.conf示例，在10秒精度的6小时后，数据被移动到60秒（1分钟）的精确度。 为了将6个数据点从10秒移动到60秒，石墨的平均值为6个数据点。 因此，它将采用最老的6个数据点的总值，并将其除以6.这给出了60秒期间每10秒的平均事件数（而不是事件总数，这是我们关心的具体而言）。这只是石墨的devise，在某些情况下可能是有用的，但在我们的情况下，这不是我们想要的。 为了“解决”这个问题，我把10秒的精确保留时间增加到了60天。 超过60天，我精确地存储了10分钟的精度，但实质上没有任何原因，因为这些数据对我们来说并不是那么有用。
我希望这有助于某人，我知道这让我很烦恼了几天 – 而且我知道没有大量的人使用这个软件堆栈来实现这个目的，所以花了一些研究才真正弄清楚了发生了什么事以及如何得到我想要的结果。