即使我发送数据，石墨对所有数据点也显示“无”

我已经使用Nginx和PostgresSQL 通过Puppet（https://forge.puppetlabs.com/dwerder/graphite）安装了Graphite 。当我手动发送数据时，它将创建度量标准，但其所有数据点均为“无”（也称为null）。如果我运行Graphite附带的example-client.py，也会发生这种情况。

echo "jakub.test 42 $(date +%s)" | nc 0.0.0.0 2003 # Carbon listens at 2003
# A minute or so later:
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | head -n1
Sun May  4 12:19:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | tail -n1
Mon May  5 12:09:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | grep -v None | wc -l
0

和：

$ python /opt/graphite/examples/example-client.py 
# Wait until it sends two batches of data ...
$ whisper-fetch.py /opt/graphite/storage/whisper/system/loadavg_15min.wsp | grep -v None | wc -l
0

根据ngrep的说法，这是[从以后尝试]到达端口的数据（第3行）：

####
T 127.0.0.1:34696 -> 127.0.0.1:2003 [AP]
  jakub.test  45 1399362193. 
####^Cexit
23 received, 0 dropped

这是以下内容的相关部分/opt/graphite/conf/storage-schemas.conf：

[default]
pattern = .*
retentions = 1s:30m,1m:1d,5m:2y

知道有什么问题吗？Carbon自己的指标和数据显示在UI中。谢谢！

环境：Ubuntu 13.10 Saucy，石墨0.9.12（通过点子）。

PS：我在这里写了有关故障排除尝试的信息- 石墨显示度量标准但没有数据–故障排除

更新：

1. 即使保留策略指定了更高的精度（例如“ 1s”或“ 10s”），耳语文件中的数据点也仅每1m分钟更新一次。
2. 数据被忽略的解决方法：要么使用带有xFilesFactor = 0.1（而不是0.5）的聚合模式，要么将最低精度设置为1m，而不是<1-49之间的数字>。-请参阅接受的答案或石墨答案的问题下方的注释。根据文档：“ xFilesFactor应该是0到1之间的浮点数，并指定以前的保留级别的时隙中必须有非零值的部分才能聚合为非零值。默认值为0.5。 ”因此，似乎无需考虑指定的1s精度，数据就汇总到1分钟，最终变为None，因为在分钟周期内少于50％的值是非None。

解

因此，@ jlawrie引导我找到解决方案。事实证明数据实际上在那里，但没有聚合，原因是双重的：

1. UI和低语获取均显示数据聚合的精度，该精度跨越整个查询周期，默认为24h。也就是说，除非您选择较短的期限，否则任何保留时间<1d的内容都不会显示在用户界面或获取中。由于我的1s保留时间为30分钟，因此我需要选择<=最近30分钟的时间，才能真正看到以最高精度收集的原始数据。
2. 汇总数据时（在我的情况下，从1s到1min），默认情况下Graphite要求该期间内50％（xFilesFactor = 0.5）的数据点具有值。如果不是，它将忽略现有值并将其聚合为“无”。因此，在我的情况下，我需要在一分钟内至少发送30次数据（30是60s的50％= 1min），以使它们显示在1min的合计值中。但是我的应用仅每10秒发送一次数据，因此我在60个值中只有6个。

=>解决方案是将第一精度从1s更改为10s，并记得在要查看原始数据时选择一个较短的时间段（或将其保留时间扩展到24h以默认显示它）。

我在使用相同的人偶模块时遇到了相同的问题。我不确定为什么，但是更改默认保留策略似乎可以解决该问题，例如

class { 'graphite':
  gr_storage_schemas => [
    {
      name       => 'carbon',
      pattern    => '^carbon\.',
      retentions => '1m:90d'
    },
    {
      name       => 'default',
      pattern    => '.*',
      retentions => '1m:14d'
    }
  ],
}

Graphite可以通过多种方式来丢失数据，这就是为什么我真正尝试避免使用它的原因。让我从一个简单的例子开始-尝试连接您的应用程序，等待一秒钟（实际上是一秒钟），然后输出带有时间戳的数据。我发现在许多情况下这都可以解决确切的问题。您应该尝试的另一件事是以比石墨记录数据的频率高得多的频率提交数据。我会再讲一点。另一个常见的错误是使用whisper-resize.py实用程序，它对我确实不起作用。如果您的数据还不重要，则只需删除耳语文件，然后使用新的保留设置来创建它们即可。

Graphite的存储文件（耳语文件）不是将数据存储为带有值和时间的点（就像您提供的程序一样），实际上是将其存储为具有一系列存储值的插槽。然后，程序尝试使用保留数据文件找出对应于时间段的时间段。我想如果它得到的数据不完全适合插槽发生的情况是它使用平均值，最小值或最大值，具体取决于保留文件所在目录中的另一个文件。我发现防止混乱的最佳方法是提交数据的频率要比石墨存储数据的频率高得多。老实说，它变得非常复杂-不仅有石墨的保留期，还有填充点的平均算法（我认为），而且这些值还应用于耳语文件。当它们不匹配时，将会发生非常奇怪的事情，因此在您的配置工作之前，我建议您反复删除您的耳语文件，然后让石墨重新创建它们。

该程序确实使我感到惊讶，因为它表现得很差劲，因此，如果您遇到类似问题，请不要以为这是您的错。