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