elasticsearch / kibana错误＆＃34;数据太大，[@timestamp]的数据会大于限制

Question

在我的测试ELK群集上，我在尝试查看上周的数据时遇到以下错误。

Data too large, data for [@timestamp] would be larger than limit

有关分片失败的警告似乎具有误导性，因为elasticsearch监控工具kopf和head表明所有分片都正常工作，弹性群集为绿色。

google group for popsearch的一位用户建议增加内存。我已将3个节点增加到8GB，每个节点有4.7GB堆，但问题还在继续。 我每天产生大约5GB到25GB的数据，保留30天。

Answer 1

清除缓存可以缓解症状。

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" }'

更新：群集移动到更快的虚拟机管理程序后，这些错误就消失了

Answer 2

问题是ES_JAVA_OPTS给Elasticsearch的内存。

尝试通过以下方式提供更多内存：ES_JAVA_OPTS =“-Xmx2g -Xms2g”。

Answer 3

_cache API还支持通过普通的URI查询参数有针对性地清除线程池中的字段数据，请求等。

原型，请参见占位符<cache type>：

$ curl -XPOST \
    -H "Content-Type: application/json" \
    'http://localhost:9200/_cache/clear?<cache type>=true'

示例

$ curl -XPOST \
    -H "Content-Type: application/json" \
    'http://localhost:9200/_cache/clear?fielddata=true'

$ curl -XPOST \
    -H "Content-Type: application/json" \
    'http://localhost:9200/_cache/clear?request=true'

注意：，您还可以定位特定的索引，在<index>下方替换：

$ curl -XPOST \
    -H "Content-Type: application/json" \
    'http://localhost:9200/<index>/_cache/clear?request=true'

参考文献

• https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-clearcache.html

Answer 4

清除缓存不适用于我们的集群。使用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堆大小的问题。