1

我相信这一定是由我设置 statsd/graphite 的方式引起的，但是我似乎无法弄清楚：

通常，当通过快速连续发送不同指标的计时器值来创建新度量时，statsd 似乎只将它应该为每个计时器创建的一些变化发送到石墨，例如，如果我执行以下操作并让它创建几个指标：

while true;do echo "test$RANDOM:38|ms" | nc -w 1 -u localhost 8125;done

我最终得到类似以下的内容，即仅为某些指标创建数据文件，但有些丢失并且即使经过一段时间也没有出现。

$ cd /opt/graphite/storage/whisper/stats/timers
$ ls test9304/
count.wsp  lower.wsp  mean_90.wsp  std.wsp  sum.wsp  upper.wsp
$ ls test31877/
count_ps.wsp  count.wsp  lower.wsp  mean_90.wsp  mean.wsp  std.wsp  sum_90.wsp  sum.wsp  upper_90.wsp  upper.wsp

似乎这些缺失的会出现在有时稍后再次发送度量之后，但它在某种程度上是不确定的，哪些是在何时创建的。

那么这是有原因的吗？某些内部优化或缓存仅在比宣传的 10 秒更长的时间后刷新内容？

4

2 回答 2

2

关于碳配置的答案是正确的方向，但是它没有解释为什么这些东西从来没有出现过，即使在 Graphite 浏览器中也没有，它应该考虑到缓存的数据。

实际原因不一样，看了一些配置文件后，我发现了以下内容，这可能与我的问题更相关：

> # Softly limits the number of whisper files that get created each minute.                                               
> # Setting this value low (like at 50) is a good way to ensure your graphite                                             
> # system will not be adversely impacted when a bunch of new metrics are                                                 
> # sent to it. The trade off is that it will take much longer for those metrics'                                         
> # database files to all get created and thus longer until the data becomes usable.                                      
> # Setting this value high (like "inf" for infinity) will cause graphite to create                                       
> # the files quickly but at the risk of slowing I/O down considerably for a while.                                       
> MAX_CREATES_PER_MINUTE = 50

这实际上解释了为什么向 statsd 发送大量新措施确实只创建了一些，但是以随机顺序......它依赖于分钟切换来实际创建新措施。

于 2014-02-21T12:20:00.273 回答
1

是的，carbon-cache（它已经在名称中）进行这种缓存以不耗尽 I/O 带宽并将多个指标一起写入，并且石墨 Web 应用程序同时使用磁盘上的文件和 RAM 中的数据。您甚至可以配置 carbon-cache 的这种行为，例如在刷新之前它收集了多少数据点（在所有指标上）。

于 2014-02-21T10:20:06.977 回答