故障排除指南：解决 Kibana Discover 加载时的 6 个常见问题
Share on Twitter在 Twitter 上分享
Share on LinkedIn在 LinkedIn 上分享
Share on Facebook在 Facebook 上分享
Share by Email通过邮件分享
Print this page打印
Discover 是 Elastic® 核心的 Kibana® UI，用于搜索、筛选和检查（时序）数据。可视化 用于数据聚合/汇总。Discover UI 对大型数据 Elasticsearch® 响应具有弹性，但有时会因（未压缩的）响应大小、映射爆炸 和浏览器限制而出现问题。
下面，我们将汇总最常见的历史问题，包括加载时间过长、超时和错误，并提供一个用于解决这些问题的顺序故障排查指南。注意：本文的 API 是针对 v8.6 版本编写的，但通用的故障排查流程适用于更早和更晚的版本。
建立并加载用户会话后，Kibana 将通过基础 URI /应用/discover（或其相关的 Kibana Space 特定 URI）加载 Discover。为加载此页面，浏览器页面将依次向 Kibana 服务器请求三个 API（并根据需要通过 Kibana 请求下方的 Elasticsearch 服务器）。
1. 加载 Data view
浏览器页面将请求 Kibana 的 Saved Objects 终端，以获取当前选定的 Data view（代码仍指向 `type:index-pattern`，因为此对象在早期版本中被称为“索引模式”，但在 8.0 版本中为了清晰起见进行了重命名）。
POST /api/saved_objects/_bulk_get
[{"id":"${INDEX_PATTERN_ID}","type":"index-pattern"}]此 Kibana API 会将搜索转发至 Saved Object（已保存对象）的底层 别名 .kibana 下的 Elasticsearch API。我不确定查询转换是否准确，但大概是这样的：
GET .kibana*/_search
{"query": {"bool": {"filter": [{"bool": {"should": [{
"match_phrase": {"_id": "index-pattern:INDEX_PATTERN_ID"}
}]}}]}}}注意：已保存对象是根据 Data view 的 ID 进行查找的，而不是根据标题或名称。如果您 导出/导入 或 复制 已保存对象，在 Kibana Spaces 或 Elasticsearch 集群之间，您可能会遇到关于底层 ID 在导入期间发生更改的可视化/仪表板/Discover 错误（请参阅已保存对象的导入模块以避免此问题）。为了演示这些字段的区别：
常见问题 2：缺失 Data view
如果这影响到您，在页面加载期间，您会看到一个类似于以下的右下角警告/错误模块： “DATA_VIEW_ID”不是已配置的 Data view ID
此错误是在当前 Kibana Space 的上下文中报告的，如果 Data View 在其他 Space 中不存在，则不适用。
2. 加载字段
接下来，Kibana UI 将加载一组底层索引的相关字段。
API。 首先，它将进行 API 请求：
GET /api/index_patterns/_fields_for_wildcard?pattern=INDEX_PATTERN&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_score每当用户在左上角选择 Data View 时，此 API 都会重新触发。在后端，Kibana 正从 Elasticsearch 的 字段 Caps API 返回索引。
常见问题 4：字段冲突
过去，索引之间的字段名称冲突曾导致错误。您可能希望修复底层的索引映射，但也可以 应用运行时字段 作为临时覆盖，以修复杂乱索引的映射类型。
JS. API 结果返回后，如果左侧抽屉（显示“已选字段”和“可用字段”）处于打开状态，浏览器 JavaScript 将对这些字段进行汇总分析。如果速度较慢，这将在浏览器“网络”选项卡中显示为：API 请求已结束，但后续的 (3) 请求在数秒内未开始尝试。用户通常只会在延迟 ≥10 秒时注意到这一点。
3. 加载搜索
最后，浏览器页面将发出一个 API 搜索请求。此 API 搜索请求会经过 Kibana 服务器，但（应该）与直接发出 Elasticsearch API 请求所花费的时间几乎相同。
API。 此 URI 默认为：
POST /internal/bsearch {REQUEST_BODY_HERE}但如果 高级设置 courier:batchSearches 被设置为 false（<v8.0），那么它将改为请求以下 API：
POST /internal/_msearch {REQUEST_BODY_HERE}
我们预计“查询时间”（Elasticsearch 认为搜索所花费的时间）与 Kibana 报告的时间之间会存在差异，但我们需要检查后者是否比前者高出几个数量级；如果是，则可能表明存在 Kibana 服务器负载、HTTP 压缩被禁用或常规渲染问题等情况。
如果我们想要进一步调查搜索，以区分 Kibana 服务器负载和常规渲染问题，我们将进一步导航至 Inspect > Request > Open in Console（又称 DevTools）。可视化效果如下：
然后，我们将同时在 DevTools 中以及通过 Elasticsearch API cURL 分别运行此 API 搜索请求，并记录 Discover、DevTools 和 Elasticsearch API 之间整体响应时间的差异。
常见问题 5：如果 Elasticsearch API 中的查询运行缓慢
如果 Elasticsearch 也和其他两者一样慢，我们可能会怀疑原始 Discover 视图中存在未优化的搜索/筛选器。如果未应用任何筛选器/搜索（或在未应用任何筛选器/搜索的情况下重现问题），我们将通过 CAT Node、CAT Threadpools（特别是搜索线程）以及 CAT Tasks（针对 长时间运行的任务）来确认 Elasticsearch 的总体性能。如果未发现集群范围的问题，我们将比较在 Discover 中选择的不同 Data view 之间的搜索响应持续时间，然后比较这些搜索相关的 Query Profiling（在我们的搜索请求正文中注入 profile: true 之后）。
JS. API 结果返回后，浏览器中的 JavaScript 会启动，以加载 1) 显示表格摘要（中下方的“文档”表格，您可以在其中切换列视图的开/关）或 2) “字段统计”（公测版，通过 高级设置 中的 discover:showFieldStatistics 进行切换）。
常见问题 6：受映射爆炸影响的渲染时间
映射爆炸 (Mapping Explosions) 可能导致巨大的结果集，这在过去曾导致浏览器性能下降（例如，kibana#144673）。映射爆炸可能会引发特定于浏览器的错误，例如 Chrome 的“Error: maximum call stack size exceeded”，该错误在隐身模式下也会重现，在 Firefox/Safari 中不会发生，有时只能通过升级 Chrome 来解决。然而，如果您在结果返回后遇到渲染过程非常缓慢且没有错误的情况，那么是时候记录浏览器性能配置文件 (Performance Profile) 以深入分析导致渲染缓慢的原因了。我们的团队很乐意通过 Kibana GitHub、Elastic Discuss 或提交 支持 (Support) 工单 来帮助您查看输出结果！
级联影响
（为辅助快速页面搜索：#devToolsAuto。）在排查潜在的映射 (Mapping) 爆炸问题时，DevTools 的响应速度可能会慢于 Discover，且在 URI 未预期请求时，左上角图标的加载速度也可能较慢。
GET /api/console/autocomplete_entities?fields=true&indices=true&templates=true&dataStreams=true
这些请求可能会拖慢 1) 本地浏览器，导致页面崩溃或出现“等待页面？”横幅广告；以及 2) Kibana Server，具体取决于请求的频率和开销。此更改仅针对当前登录的用户。
结论
Discover 功能可以轻松查看集群中多个索引的数据。某些配置和设置可能会导致此 UI 加载速度过慢。本指南详细介绍了这些潜在问题的影响；不过，良好的数据卫生习惯可以避免所有这些问题。有关更多数据卫生技巧，请参阅我们的Elasticsearch 文档。
本文中描述的任何功能或功能性的发布和时间均由 Elastic 自行决定。当前尚未发布的任何功能或功能性可能无法按时提供或根本无法提供。
分享
- Share on Twitter
在 Twitter 上分享
- Share on LinkedIn
在 LinkedIn 上分享
- Share on Facebook
在 Facebook 上分享
- Share by Email
通过邮件分享
- Print this page
打印