Reporting troubleshooting

edit

Having trouble? Here are solutions to common problems you might encounter while using Reporting.

Verbose logs

edit

Kibana server logs have a lot of useful information for troubleshooting and understanding how things work. If you’re having any issues at all, the full logs from Reporting will be the first place to look. In kibana.yml:

logging.verbose: true

For more information about logging, see Kibana configuration settings.

System dependencies

edit

Reporting launches a "headless" web browser called Chromium on the Kibana server. It is a custom build made by Elastic of an open source project, and it is intended to have minimal dependencies on OS libraries. However, the Kibana server OS might still require additional dependencies for Chromium.

Make sure Kibana server OS has the appropriate packages installed for the distribution.

If you are using CentOS/RHEL systems, install the following packages: * ipa-gothic-fonts * xorg-x11-fonts-100dpi * xorg-x11-fonts-75dpi * xorg-x11-utils * xorg-x11-fonts-cyrillic * xorg-x11-fonts-Type1 * xorg-x11-fonts-misc * fontconfig * freetype

If you are using Ubuntu/Debian systems, install the following packages: * fonts-liberation * libfontconfig1

Text is rendered incorrectly in generated reports

edit

If a report label is rendered as an empty rectangle, no system fonts are available. Install at least one font package on the system.

If the report is missing certain Chinese, Japanese or Korean characters, ensure that a system font with those characters is installed.

Missing data in PDF report of data table visualization

edit

There is currently a known limitation with the Data Table visualization that only the first page of data rows, which are the only data visible on the screen, are shown in PDF reports.

File permissions

edit

Ensure that the headless_shell binary located in your Kibana data directory is owned by the user who is running Kibana, that the user has the execute permission, and if applicable, that the filesystem is mounted with the exec option.

The Chromium binary is located in the Kibana installation directory as data/headless_shell-OS_TYPE/headless_shell. The full path is logged the first time Kibana starts when verbose logging is enabled.

Error messages

edit

Whenever possible, a Reporting error message tries to be as self-explanatory as possible. Here are some error messages you might encounter, along with the solution.

StatusCodeError: [version_conflict_engine_exception]

edit

If you are running multiple instances of Kibana in a cluster, the instances share the work of executing report jobs to evenly distribute the work load. Each instance searches the reporting index for "pending" jobs that the user has requested. It is possible for multiple instances to find the same job in these searches. Only the instance that successfully updated the job status to "processing" will actually execute the report job. The other instances that unsuccessfully tried to make the same update will log something similar to this:

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
}

These messages alone don’t indicate a problem. They show normal events that happen in a healthy system.

Max attempts reached

edit

There are two primary causes of this error:

  1. You’re creating a PDF of a visualization or dashboard that spans a large amount of data and Kibana is hitting the xpack.reporting.queue.timeout
  2. Kibana is hosted behind a reverse-proxy, and the Kibana server settings are not configured correctly

Create a Markdown visualization and then create a PDF report. If this succeeds, increase the xpack.reporting.queue.timeout setting. If the PDF report fails with "Max attempts reached," check your Kibana server settings.

"You must install nss for Reporting to work"

edit

Reporting using the Chromium browser relies on the Network Security Service libraries (NSS). Install the appropriate nss package for your distribution.

"Unable to use Chromium sandbox"

edit

Chromium uses sandboxing techniques that are built on top of operating system primitives. The Linux sandbox depends on user namespaces, which were introduced with the 3.8 Linux kernel. However, many distributions don’t have user namespaces enabled by default, or they require the CAP_SYS_ADMIN capability.

Elastic recommends that you research the feasibility of enabling unprivileged user namespaces before disabling the sandbox. An exception is if you are running Kibana in Docker because the container runs in a user namespace with the built-in seccomp/bpf filters.