我用nginx和PostgresSQL通过Puppet( https://forge.puppetlabs.com/dwerder/graphite )安装了Graphite。 当我手动发送数据时,它会创build度量标准,但其所有数据点都是“无”(aka 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
任何想法是什么错误? 碳的自己的指标和数据显示在用户界面。 谢谢!
环境:Ubuntu 13.10 Saucy,石墨0.9.12(通过pip)。
PS:我写过关于我的故障排除尝试 – 石墨显示度量但没有数据 – 故障排除
更新 :
xFilesFactor = 0.1 (而不是0.5)的聚合模式,或者将最低精度设置为1m,而不是1-49>之间的<数字。 – 请参阅接受的答案或Graphite Answers问题下方的注释。 根据文档 :“ xFilesFactor应该是一个介于0和1之间的浮点数,并指定以前保留级别的槽的哪一部分必须具有非空值才能聚合为非空值,默认值为0.5。 “因此,如果不考虑指定1的精度,则数据会聚合到1分钟,因为分钟内的值不足50%是非无。 解
所以@jlawrie引导我去解决问题。 事实certificate,这些数据实际上是在那里,但总是没有什么,原因是双重的:
=>解决scheme是将第一个精度从1秒改为10秒,并记得当我想看到原始数据(或将其保留时间延长到24小时以显示默认值)时select较短的时间段。
我使用相同的傀儡模块遇到了同样的问题。 我不完全确定为什么,但更改默认保留策略似乎修复它,例如
class { 'graphite': gr_storage_schemas => [ { name => 'carbon', pattern => '^carbon\.', retentions => '1m:90d' }, { name => 'default', pattern => '.*', retentions => '1m:14d' } ], }
Graphite有很多方法会丢失数据,这就是为什么我真的试图避免使用它。 让我从一个简单的开始 – 尝试让您的应用程序连接,等待一秒(字面上一秒),然后输出时间戳数据。 我发现在许多情况下,这将解决确切的问题。 你应该尝试的另一件事是提交数据的频率远高于石墨logging数据的频率。 我会进一步。 另一个常见的错误是使用whisper-resize.py实用程序,这实际上不适合我。 如果你的数据不重要,只要删除耳语文件,让他们创build新的保留设置。
Graphite的存储文件,耳语文件,而不是将数据存储为具有值和时间的点(就像您提供的程序一样),实际上将其存储为具有存储值的一系列插槽。然后程序尝试找出使用保留数据文件的时间段对应的插槽。 如果它得到的数据不完全适合插槽,我认为会发生什么是使用平均值,最小值或最大值取决于保留文件在同一目录中的另一个文件。 我发现最好的办法就是把所有东西搞乱,就是提交数据的频率要比石墨储存数据的频率高得多。 它真的变得非常复杂 – 不仅有石墨的保留期,平均algorithm填补点(我认为),但这些值也适用于耳语文件。 很奇怪的事情会发生时,这些不匹配,所以直到你的configuration工作,我会build议反复删除你的耳语文件,让石墨重新创build它们。
这个程序真的让我觉得行事相当麻烦,所以如果你遇到这样的事情,不要以为这是你的错。