elasticsearch / kibana 错误“数据太大，[@timestamp] 的数据将大于限制答案

【问题标题】：elasticsearch / kibana errors "Data too large, data for [@timestamp] would be larger than limitelasticsearch / kibana 错误“数据太大，[@timestamp] 的数据将大于限制
【发布时间】：2015-06-30 21:01:56
【问题描述】：

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

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

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

弹性搜索的 google 组中的一位用户建议增加内存。我已将 3 个节点增加到 8GB，每个节点有 4.7GB 堆，但问题仍然存在。我每天生成大约 5GB 到 25GB 的数据，保留 30 天。

【问题讨论】：

标签： kibana kibana-4 elasticsearch

【解决方案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" }'

更新：一旦集群迁移到更快的虚拟机管理程序，这些错误就会消失

【讨论】：

我遇到了同样的问题，清除缓存解决了这些问题。我不确定这是否需要定期进行。谢谢！
这成功了！谢谢！尽管使用 ES 已经好几年了，但之前从未见过这个问题......非常奇怪。
是的，遇到了同样的问题并清除了缓存，一切又恢复了。点赞并为问题加注星标。
只有最后一个对我有用，即使我只查询其中一个索引
@spuder +1，帮了大忙。

【解决方案2】：

问题在于 ES_JAVA_OPTS 给 Elasticsearch 的内存。

尝试提供更多内存：ES_JAVA_OPTS="-Xmx2g -Xms2g"。

【讨论】：

【解决方案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

【讨论】：

如果不包含正文，则不需要 Content-Type

【解决方案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 堆大小的问题。

【讨论】：