使用StatsD（通过etsy）和Graphite跟踪指标，石墨图似乎没有绘制所有数据的图形

Question

我们有一个度量标准，每当用户在我们的网站上执行特定操作时，我们就会增加这个度量标准，似乎是准确的。

因此，我们放弃了这个预感，投入了碳的updates.log，发现这个行为今天发生了4000多次（使用grep和wc），但根据图的积分结果，它只返回220ish。

这可能是什么原因造成的？数据正在使用statsd php库进行统计，并且调用statsd::increment('metric');，并且如上所述，日志证实今天发生了对此密钥的4000多个更新。

我们使用：

石墨0.9.6与statsD（Etsy的）

Answer 1

发布我的评论上述，我发现石墨0.9.9之后有一个（新的？）配置文件，存储aggregation.conf，其中一个可以控制每个模式的聚合方法。可用选项包括平均值，总和，最小值，最大值和最后值。

http://readthedocs.org/docs/graphite/en/latest/config-carbon.html#storage-aggregation-conf

Answer 2

通过文档经过一番研究，以及一些谈话与其他人，我已经找到了问题 - 和解决方案。

耳语文件格式的设计方式，它期望您（或您的应用程序）发布更新不会比您的storage-schemas.conf文件中的最小间隔更快。该文件用于配置您在不同的时间间隔分辨率下保留的数据量。

我的storage-schemas.conf文件设置为最小保留时间为1分钟。默认的StatsD守护进程（来自etsy）旨在每10秒更新一次碳（石墨守护进程）。这是一个问题的原因是：在60秒的时间段内，StatsD报告了6次，每次写入覆盖最后一次（在60秒的时间间隔内，因为您每分钟更新一次）。这会在您的图表上产生非常奇怪的结果，因为一分钟内最后10秒钟可能完全死亡，并在该时间段内报告活动为0，这会导致您在那一刻写入的所有数据完全无效。

为了解决这个问题，我不得不重新配置我的storage-schemas.conf文件以10秒的最大分辨率存储数据，因此StatsD的每次更新都会保存在whisper数据库中而不会被覆盖。

Etsy的公布，他们使用它们的安装的碳，它看起来像这样的storage-schemas.conf配置：

[stats] 
priority = 110 
pattern = ^stats\..* 
retentions = 10:2160,60:10080,600:262974 

这具有10秒的最小保持时间，并且存储值得其中6小时。但是，由于我的下一个问题，我大大延长了保留期限。

由于我让这些数据收集了几天，我注意到它仍然看不到（并且正在报告中）。这是由于2个问题。

1. StatsD（旧版本）仅报告了每10秒钟报告周期的平均每秒事件数。这意味着，如果你在1秒内增加一次键100次，在接下来的9秒内增加0次，在第10秒结束时，统计数据会向石墨报告10，而不是100.（100/10 = 10）。这未能报告10秒钟的事件总数（显然）。
   
   较新版本的statsD修复了此问题，因为它们引入了stats_counts存储桶，该存储桶记录了每10秒期间每个指标的总事件数量（因此，报告中没有报告前10个示例中的10个报告）。
   
   后，我升级StatsD，我注意到，在过去的6个小时的数据看起来不错，但我看了以后在最后6小时 - 事情看起来奇怪，接下来的原因就是：

2. 石墨存储数据，它将数据从高精度保留移到更低精度保留。这意味着，使用例子，在10秒精确度的6小时后，数据移动到60秒（1分钟）的精确度。为了将6个数据点从10秒移动到60秒精度，石墨的平均值为6个数据点。因此，它会采取最古老的6个数据点的总价值，并通过6把它这给了每10秒可活动的平均＃的，有60第二阶段（而不是事件的总＃，这是我们关心具体地说）。
   
   这是石墨仅仅是如何设计的，对于某些情况下，它可能是有用的，但是对我们来说，这不是我们想要的。为了“解决”这个问题，我将10秒的精确保留时间增加到了60天。超过60天后，我保存了每分钟10分钟的精度，但基本上没有任何原因，因为这些数据对我们来说没有那么有用。

我希望这可以帮助别人，我知道这让我生气了几天 - 我知道没有一个巨大的正在使用该堆栈软件用于此目的的人的社区，所以花了一点研究，以真正弄清楚发生了什么事情，以及如何得到我想要的结果。