1

使用statsd，配置flushInterval: 1000并与石墨的 carbon-cache通信。我希望我能看到非常偶然的柜台。

我有以下碳配置：

存储架构.conf：

[carbon]
pattern = ^carbon\.
retentions = 60:90d

[default_30s_for_1day]
pattern = .*
retentions = 30s:1d

以这种方式发送一个独特的计数器：

$ echo "foobar:1|c" > /dev/udp/127.0.0.1/8125

我可以看到statsd收到的数据包：

9 Jul 14:43:05 - DEBUG: foobar:1|c

以及发送到 carbon-cache 的数据（tcpdump 提取）：

stats.foobar 1 1404909785

在石墨中，查看“foobar”的数据，我可以看到那一刻发生了一些事情（细线，见图片中的红色圆圈），但结果始终为“0”：

在此处输入图像描述

我错过了什么吗？

如果有更频繁的结果，那么我可以看到看起来正确的数字。

是否有最低数量的统计数据需要考虑？是否可配置？

注意：也许对于这种偶尔的数据 StatsD / Graphite 是不值得的，但由于为同一个项目收集了其他非常频繁的数据，无论如何都会使用这些数据，并希望可以使用一个独特的解决方案，即使对于罕见的计数器。

4

1 回答 1

3

我的设置中的问题是flushInterval（1 秒）低于我的最小保留时间（30 秒）

每（我的情况：30 秒），carbon-cache 都会存储结果，但是，例如，如果在第二个“10”为我的foobar键发送计数“1”，则 statsd 将每秒发送一次计数“0”（每个 flushInterval 更准确）之后。这意味着在第二个“30”处，foobar看到的最后一个值是“0”。考虑值“1”的唯一机会是如果它是在最晚的时刻发送的，就在第二个“30”之前。

可以怪我不使用 statsddeleteIdleStats或deleteCounters设置不发送“0”。但是这样做，在同一 30 秒内将两次计数器设置为“1”。slot 会错过第一个计数器，导致注册的计数为“1”而不是“2”。

真正的解决方案是使 statsdflushInterval与碳的最小保留量保持一致：

statsd config.js：

flushInterval: 10000

carbon 的 storage-schemas.conf：

retentions = 10s:1d,1m:30d,5m:90d
于 2014-07-09T16:18:50.240 回答