报告故障排除

遇到问题？以下是一些在使用 Reporting 时可能遇到的常见问题的解决方案。

报告诊断编辑

Reporting 带有一个内置实用程序，可以尝试自动查找常见问题。当 Kibana 运行时，导航到报告列表页面，然后单击 运行报告诊断。这将打开一个诊断工具，该工具会检查 Kibana 部署的各个部分，并提出任何相关的建议。

如果诊断信息没有揭示问题，您可以通过使用环境变量启动 Kibana 服务器来进一步进行故障排除，以显示其他调试日志。请参阅 Puppeteer 调试日志。

生成的报告中文本渲染不正确编辑

如果报告标签被渲染为空矩形，则没有可用的系统字体。在系统上安装至少一个字体包。

如果报告缺少某些中文、日文或韩文字符，请确保安装了包含这些字符的系统字体。

数据表可视化效果的 PDF 报告中缺少数据编辑

目前，数据表可视化效果存在一个已知限制，即只有第一页数据行（即屏幕上可见的唯一数据）会显示在 PDF 报告中。

文件权限编辑

确保位于 Kibana 数据目录中的 headless_shell 二进制文件归运行 Kibana 的用户所有，该用户具有执行权限，并且如果适用，文件系统已使用 exec 选项挂载。

错误消息编辑

在可能的情况下，Reporting 错误消息会尽可能地自解释。以下是一些您可能会遇到的错误消息，以及相应的解决方案。

StatusCodeError: [version_conflict_engine_exception]编辑

如果您在集群中运行多个 Kibana 实例，这些实例会共享执行报告作业的工作，以平均分配工作负载。每个实例都会搜索报告索引以查找用户请求的“待处理”作业。多个实例可能会在这些搜索中找到相同的作业。只有成功将作业状态更新为“处理中”的实例才会实际执行报告作业。其他尝试进行相同更新但未成功的实例将记录类似于以下内容的内容

StatusCodeError: [version_conflict_engine_exception] [...]: version conflict, required seqNo [6124], primary term [1]. current document has seqNo [6125] and primary term [1], with { ... }
  status: 409,
  displayName: 'Conflict',
  path: '/.reporting-...',
  body: {
    error: {
      type: 'version_conflict_engine_exception',
      reason: '[...]: version conflict, required seqNo [6124], primary term [1]. current document has seqNo [6125] and primary term [1]',
    },
  },
  statusCode: 409
}

这些消息本身并不表示问题。它们显示了正常系统中发生的正常事件。

达到最大尝试次数编辑

此错误有两个主要原因

创建 Markdown 可视化效果，然后创建 PDF 报告。如果成功，请增加 xpack.reporting.queue.timeout 设置。如果 PDF 报告失败并显示“达到最大尝试次数”，请检查您的 Kibana 服务器设置。

您必须安装 nss 才能使 Reporting 工作编辑

使用 Chromium 浏览器的 Reporting 依赖于网络安全服务库 (NSS)。为您的发行版安装相应的 nss 包。

无法使用 Chromium 沙箱编辑

Chromium 使用基于操作系统原语的沙箱技术。Linux 沙箱依赖于用户命名空间，这些命名空间是在 3.8 Linux 内核中引入的。但是，许多发行版默认情况下没有启用用户命名空间，或者它们需要 CAP_SYS_ADMIN 功能。如果在 Kibana 中没有明确禁用沙箱（基于操作系统检测或使用 xpack.screenshotting.browser.chromium.disableSandbox 设置），Chrome 将尝试启用沙箱。如果由于操作系统或权限限制而失败，Chrome 将在初始化期间崩溃。

Elastic 建议您在禁用沙箱之前研究启用无特权用户命名空间的可行性。一个例外是，如果您在 Docker 中运行 Kibana，因为容器在具有内置 seccomp/bpf 过滤器的用户命名空间中运行。

详细日志编辑

Kibana 服务器日志包含大量有用的信息，可用于故障排除和了解事物的工作原理。如果您遇到任何问题，Reporting 的完整日志将是首先要查看的地方。在 kibana.yml 中

logging.root.level: all

有关日志记录的更多信息，请参阅 Kibana 配置设置。

Puppeteer 调试日志编辑

Kibana 在服务器上启动的 Chromium 浏览器由一个名为 Puppeteer 的 Chromium NodeJS 库驱动。Puppeteer 库有自己的命令行方法来生成自己的调试日志，这些日志有时可能会有所帮助，特别是为了确定问题是由 Kibana 还是 Chromium 引起的。请参阅 调试技巧了解更多信息。

在启动 Kibana 时使用 Puppeteer 的调试方法将类似于

env DEBUG="puppeteer:*" ./bin/kibana

内部 DevTools 协议流量将通过 debug 模块在 puppeteer 命名空间下进行记录。

Puppeteer 日志非常详细，可能包含敏感信息。请谨慎处理生成的输出。

系统要求编辑

在 Elastic Cloud 中，大多数配置默认提供的 Kibana 实例的内存为 1GB。当可视化效果或仪表板相对简单时（例如单个饼图或包含几个可视化效果的仪表板），这足以满足 Kibana Reporting 的需求。但是，某些可视化效果类型比其他类型占用更多负载。例如，TSVB 面板需要大量网络请求才能渲染。

如果 Kibana 实例没有足够的内存来运行报告，则报告将失败并出现错误，例如 Error: Page crashed! 在这种情况下，请尝试将 Kibana 实例的内存增加到 2GB。

无法连接到 Elastic Maps Service编辑

Elastic Maps Service (EMS) 是一项托管行政边界图块层和矢量形状的服务。如果报告包含缺少底图层或行政边界的映射，则 Kibana 服务器将无法访问 EMS。请参阅 连接到 Elastic Maps Service，了解有关如何将 Kibana 服务器连接到 EMS 的信息。

为 Darwin 手动安装 Chromium 浏览器编辑

Chromium 未嵌入到 Darwin (Mac OS) 架构的 Kibana 中。在 Darwin 上运行 Kibana 时，Reporting 将在服务器首次启动时将 Chromium 下载到 Kibana 安装路径的适当区域。如果服务器无法访问互联网，则必须下载 Chromium 浏览器并将其安装到 Kibana 安装路径中。

当 Kibana 启动时，它将自动从 zip 文件中提取浏览器，然后准备生成 PNG 和 PDF 报告。