在我的测试ELK群集上,我在尝试查看上周的数据时遇到以下错误。
Data too large, data for [@timestamp] would be larger than limit
关于碎片失败的警告似乎具有误导性,因为弹性搜索监测工具kopf
和head
显示所有碎片都正常工作,弹性簇是绿色的。
用于弹性搜索的google组中的一个用户建议增加内存。我已将3个节点增加到8GB,每个节点有4.7GB堆,但问题还在继续。我每天产生大约5GB到25GB的数据,保留30天。
清除缓存可以缓解症状。
http://www.elastic.co/guide/en/elasticsearch/reference/current/indices-clearcache.html
清除单个索引
curl -XPOST 'http://localhost:9200/twitter/_cache/clear'
清除多个指数
curl -XPOST 'http://localhost:9200/kimchy,elasticsearch/_cache/clear'
curl -XPOST 'http://localhost:9200/_cache/clear'
或者由IRC中的用户建议。这个似乎是最好的。
curl -XPOST 'http://localhost:9200/_cache/clear' -d '{ "fielddata": "true" }'
更新:一旦群集移动到更快的虚拟机管理程序,这些错误就会消失
清除缓存不适用于我们的群集。当使用http://x.x.x.x:9200/_cat/indices?v&s=index:desc检查各个节点时,一个给出了上述错误,其他节点有无效的指针错误。我重新启动弹性服务,给出速率限制/数据太大的错误。当它重新联机时,有一些未分配的分片,我通过将复制计数降低到较低的数量来修复(只需要在其中一个节点上执行此操作以更改群集的索引设置):
IFS=$'\n'
for line in $(curl -s 'elastic-search.example.com:9200/_cat/shards' | fgrep UNASSIGNED); do
INDEX=$(echo $line | (awk '{print $1}'))
echo start $INDEX
curl -XPUT "elastic-search.example.com:9200/$INDEX/_settings" -d '{
"index" : {
"number_of_replicas" : 1
}
}
'
done
# Check shard/cluster status (may take some time to rebalance):
# http://elastic-search.example.com:9200/_cat/shards?v&s=index:desc
# http://elastic-search.example.com:9200/_cluster/health?pretty
https://discuss.elastic.co/t/data-too-large/32141似乎也提到它可能是JVM堆大小的问题。