使用StatsD(通过etsy)和Graphite跟踪指标,石墨图似乎没有绘制所有数据

Question

我们有一个度量标准,每当用户在我们的网站上执行某个操作时,我们就会递增,但这些图表似乎并不准确.

为了摆脱这种预感,我们投入了updated.log的碳,并发现今天的动作发生了超过4千次(使用grep和wc),但根据图的积分结果,它只返回220ish.

可能是什么原因造成的？正在使用statsd php库向statsd报告数据,并且statsd::increment('metric');如上所述,该日志确认此密钥今天发生了4,000多次更新.

我们正在使用:

石墨0.9.6,带有statsD(etsy)

Answer 1

经过文档的一些研究,以及与他人的一些对话,我发现了问题 - 以及解决方案.

设计耳语文件格式的方式,它希望您(或您的应用程序)发布更新的速度不会超过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个问题.

1. StatsD(旧版本)仅报告每10秒报告期间每秒的平均事件数.这意味着,如果您在1秒内增加一次键100次,在接下来的9秒内增加0次,则在第10秒结束时,statsD将向石墨报告10,而不是100.(100/10 = 10).这未能报告10秒钟内的事件总数(显然).
   
   较新版本的statsD解决了这个问题,因为它们引入了stats_counts存储桶,它记录每10秒周期内每个指标的事件总数(因此,在上一个示例中报告10,而不是报告100).
   
   在我升级StatsD之后,我注意到最近6个小时的数据看起来很棒,但是当我看过去6个小时之后 - 事情看起来很奇怪,下一个原因是为什么:

2. 由于石墨存储数据,它将数据从高精度保留移动到较低精度保留.这意味着,使用etsy storage-schemas.conf示例,在10秒精度的6小时后,数据被移动到60秒(1分钟)精度.为了将6个数据点从10s精确到60s精度,石墨平均处理6个数据点.因此,它取最旧的6个数据点的总值,并除以6.这给出了60秒期间每10秒的平均事件数#(而不是事件的总数,这是我们关心的特别是).
   
   这就是石墨的设计方式,在某些情况下它可能有用,但在我们的例子中,它不是我们想要的.为了"修复"这个问题,我将10秒的精确保留时间增加到60天.超过60天,我存储了精确和10分钟的精度,但它们基本上没有任何理由,因为这些数据对我们没那么有用.

我希望这对某人有所帮助,我知道它让我烦恼了几天 - 而且我知道没有一个庞大的社区人群正在使用这一堆软件来实现这个目的,所以需要一些研究来真正弄清楚发生了什么以及如何获得我想要的结果.

Answer 2

在上面发表我的评论之后,我发现Graphite 0.9.9有一个(新的？)配置文件storage-aggregation.conf,其中可以控制每个模式的聚合方法.可用选项包括平均值,总和,最小值,最大值和最后值.

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