映射爆炸

编辑

Elasticsearch 的搜索和 Kibana 的 Discover Javascript 渲染依赖于搜索支持的索引中所有映射深度的映射字段总数。当这个总数过高或呈指数级增长时,我们称之为出现映射爆炸。字段计数如此之高的情况并不常见,通常表明上游文档格式存在问题,如此博客所示

映射爆炸可能会表现为以下性能症状:

  • CAT nodes 报告主节点和/或托管索引分片的节点上的堆或 CPU 使用率很高。这可能会升级为临时节点无响应和/或主节点过载。
  • CAT tasks 报告仅与此索引或多个索引相关的搜索持续时间很长,即使是简单的搜索也是如此。
  • CAT tasks 报告仅与此索引或多个索引相关的索引持续时间很长。这通常与待处理的任务报告协调节点正在等待所有其他节点确认它们已收到映射更新请求有关。
  • Discover 的通配符字段页面加载 API 命令或 Dev Tools 页面刷新的自动完成 API 命令花费很长时间(超过 10 秒)或在浏览器的开发者工具网络选项卡中超时。有关更多信息,请参阅我们关于排查 Discover 问题的演练
  • Discover 的可用字段在浏览器的开发者工具性能选项卡中花费很长时间来编译 Javascript。这可能会升级为临时浏览器页面无响应。
  • Kibana 的警报安全规则可能会报错 内容长度 (X) 大于允许的最大字符串 (Y),其中 X 是尝试的有效负载,Y 是 Kibana 的 server-maxPayload
  • Elasticsearch 启动持续时间很长。

预防或准备

编辑

映射一旦初始化就无法减少字段。Elasticsearch 索引默认为动态映射,除非与覆盖index.mapping.total_fields.limit结合使用,否则通常不会导致问题。默认的 1000 限制被认为是宽松的,尽管根据使用情况,覆盖为 10000 不会产生明显的性能影响。但是,举一个不好的例子,如果覆盖为 100000 并且映射总数达到了这个限制,通常会对性能产生很大的影响。

如果您的索引映射字段预计包含大量任意键,您可以考虑以下方法:

修改为嵌套数据类型并不能解决核心问题。

检查问题

编辑

要确认索引的字段总数以检查是否存在映射爆炸,请执行以下操作:

  • 在 Elasticsearch 集群日志中检查是否存在错误 索引 [Y] 中的字段总数限制 [X] 已超出,其中 Xindex.mapping.total_fields.limit 的值,Y 是您的索引。相关的摄取源日志错误将是 添加新字段 [Z] 时,字段总数限制 [X] 已超出,其中 Z 是尝试的新字段。
  • 对于顶级字段,轮询字段能力以获取 fields=*
  • 获取映射的输出中搜索 "type"
  • 如果您倾向于使用第三方工具 JQ,您可以处理获取映射mapping.json 输出。

    $ cat mapping.json | jq -c 'to_entries[]| .key as $index| [.value.mappings| to_entries[]|select(.key=="properties") | {(.key):([.value|..|.type?|select(.!=null)]|length)}]| map(to_entries)| flatten| from_entries| ([to_entries[].value]|add)| {index: $index, field_count: .}'

您可以使用分析索引磁盘使用情况来查找从未使用过或很少填充的字段,作为轻松的胜利。

复杂的爆炸

编辑

映射爆炸还涵盖当单个索引字段总数在限制范围内,但合并的索引字段总数非常高的情况。通常情况下,症状首先在数据视图中被注意到,并通过解析索引 API追溯到单个索引或索引子集。

但是,尽管不常见,但有可能仅在支持索引的组合上体验到映射爆炸。例如,如果数据流的支持索引都达到字段总数限制,但每个索引都包含彼此唯一的字段。

这种情况最容易通过添加数据视图并检查其字段选项卡的总字段计数来发现。此统计信息会告诉您所有字段,而不仅仅是 index:true 的字段,但可以作为良好的基线。

如果您的仅通过数据视图出现问题,如果您未使用多字段,您可以考虑此菜单的字段过滤器。或者,您可以考虑使用更有针对性的索引模式或使用否定模式来过滤掉有问题的索引。例如,如果 logs-* 由于有问题的支持索引 logs-lotsOfFields-* 而导致字段计数过高,那么您可以更新为 logs-*,-logs-lotsOfFields-*logs-iMeantThisAnyway-*

解决

编辑

映射爆炸不容易解决,因此最好通过上述方法预防。遇到这种情况通常表明上游数据发生意外更改或计划失败。如果遇到,我们建议您审查数据架构。以下选项是本页前面讨论的选项的补充;应根据最佳用例应用它们:

拆分索引不会解决核心问题。