Elasticsearch / Kibana 字段数据太大答案

【问题标题】：Elasticsearch / Kibana field data too largeElasticsearch / Kibana 字段数据太大
【发布时间】：2015-04-28 17:57:56
【问题描述】：

我有一个小型 ELK 集群正在测试中。 kibana web 界面非常慢并且会抛出很多错误。

卡夫卡 => 8.2
Logstash => 1.5rc3（最新）
Elasticsearch => 1.4.4（最新）
Kibana => 4.0.2（最新）

在 Ubuntu 14.04 上，elasticsearch 节点每个都有 10GB 的内存。我每天要获取 5GB 到 20GB 的数据。

在 kibana Web 界面中运行一个只有 15 分钟数据的简单查询也需要几分钟，而且经常会引发错误。

[FIELDDATA] Data too large, data for [timeStamp] would be larger than limit of [3751437926/3.4gb]]

这些关于分片失败的错误只出现在 kibana 中。根据所有其他插件（head，kopf），elasticsearch 分片非常好，集群是绿色的。

我已经检查了 google 组 IRC 并查看了堆栈溢出。似乎唯一的解决方案是增加内存。我已经两次增加了节点上的内存。虽然这似乎可以解决一两天，但问题很快又回来了。其他解决方案（例如清理缓存）没有长期改进。

curl -XPUT 'http://elastic.example.com:9200/cache/clear?filter=true'
curl -XPOST 'http://elastic.example.com:9200/_cache/clear' -d '{ "fielddata": "true" }'

根据 KOPF 插件，在完全空闲的集群上，堆空间量通常接近 75%。（我是公司中唯一使用它的人）。 3 个具有 10GB 内存的节点对于我拥有的数据量应该绰绰有余。

我也尝试将断路器调整为suggested by this blog.

PUT /_cluster/settings -d '{ "persistent" : { "indices.breaker.fielddata.limit" : "70%" } }'
PUT /_cluster/settings -d '{ "persistent" : {  "indices.fielddata.cache.size" : "60%" } }'

如何防止这些错误，并解决 kibana 的极度缓慢问题？

https://github.com/elastic/kibana/issues/3221
elasticsearch getting too many results, need help filtering query
http://elasticsearch-users.115913.n3.nabble.com/Data-too-large-error-td4060962.html

更新

我有大约 30 天的 logstash 索引。 2x 复制，即每天 10 个分片。

更新2

我已将每个节点的内存增加到 16GB（总共 48GB），并且我还升级到了 1.5.2。

这似乎可以解决一两天的问题，但问题又回来了。

更新3

This blog article from an elastic employee has good tips 解释导致这些问题的原因。

【问题讨论】：

至于速度问题，卷曲同一个查询是否也很慢？
我不确定如何使用 curl 进行查询。我所做的只是打开 kibana，并尝试查看最近 15 分钟的数据。没有搜索，没有查询，没有过滤器。
关于 Update2：RAM 的增加使您可以运行更多数据，但您仍然遇到同样的问题，因为索引的数据太多，ES 无法将其全部加载内存来运行查询。这对于“重度”Logstash 用户来说是一个常见问题，因为 LS 默认索引所有内容。您可以尝试做的是在其根部调整您的 LS 设置，以便您只索引重要字段并忽略（或至少不索引）其他字段。否则，正如我在下面建议的那样， doc_values 会节省您的时间，但使用大型 LS 映射来放置有点乏味。

标签： elasticsearch

【解决方案1】：

您正在索引大量数据（如果您每天添加/创建 5 到 20GB）并且您的节点内存非常低。您不会在索引方面看到任何问题，但在单个或多个索引上获取数据会导致问题。请记住，Kibana 在后台运行查询，而您收到的消息基本上是在说“我无法为您获取该数据，因为我需要在内存中放入比我拥有的更多的数据可用于运行这些查询。"

有两件事相对简单，应该可以解决您的问题：

升级到ElasticSearch 1.5.2（主要性能改进）
当您的内存不足时，您确实需要在所有映射中使用doc_values，因为这会大大减少堆大小

关键在于 doc_values。您需要修改映射以将此属性设置为 true。粗略的例子：

[...],
"properties": {
    "age": {
      "type": "integer",
      "doc_values": true
    },
    "zipcode": {
      "type": "integer",
      "doc_values": true
    },
    "nationality": {
      "type": "string",
      "index": "not_analyzed",
      "doc_values": true
    },
    [...]

更新您的映射将使未来的索引考虑到这一点，但您需要完全重新索引现有的索引，以便 doc_values 应用于现有索引。（有关更多提示，请参阅 scan/scroll 和 this 博客文章。）

副本有助于扩展，但如果您不减少每个节点的堆大小，也会遇到同样的问题。至于你目前拥有的分片数量，可能不是必要的，也不是最优的，但我认为这不是你问题的根本原因。

请记住，上述建议是为了让 Kibana 运行查询并向您显示数据。速度很大程度上取决于您设置的日期范围、您拥有的机器（CPU、SSD 等）以及每个节点上的可用内存。

【讨论】：

【解决方案2】：

基本思路包括：

打开的索引更少。
碎片更少。
使用 doc_values。

哦，还有：

更多内存。

【讨论】：

每天 10 个分片和 30 个索引是不是太多了？这似乎是默认设置。