Reporting settings in Kibana


Reporting settings in Kibanaedit

You can configure xpack.reporting settings in your kibana.yml to:

Enable reportingedit

xpack.reporting.enabled logo cloud
When true, enables the reporting features. Set this to false to disable reporting features entirely. The default is true.

Disabling the reporting features is discouraged. If you need to turn off the ability to generate reports, configure the roles and spaces in the Kibana application privileges.

If needed, you can also prevent a Kibana instance from claiming reporting work by setting xpack.reporting.queue.pollEnabled: false.

Encryption key settingedit

By default, an encryption key is generated for the reporting features each time you start Kibana. If a static encryption key is not persisted in the Kibana configuration, any pending reports fail when you restart Kibana.

If you are load balancing across multiple Kibana instances, each instance needs to have the same reporting encryption key. Otherwise, report generation fails if a report is queued through one instance, and another instance picks up the job from the report queue. The instance that picks up the job is unable to decrypt the reporting job metadata.

xpack.reporting.encryptionKey logo cloud
The static encryption key for reporting. Use an alphanumeric text string that is at least 32 characters. By default, Kibana generates a random key when it starts, which causes pending reports to fail after restart. Configure xpack.reporting.encryptionKey to preserve the same key across multiple restarts and multiple Kibana instances.
xpack.reporting.encryptionKey: "something_secret"

Reporting index settingedit


[7.11.0] Deprecated in 7.11.0. This setting will be removed in 8.0.0. Reporting uses a weekly index in Elasticsearch to store the reporting job and the report content. The index is automatically created if it does not already exist.

When you divide workspaces in an Elastic cluster using multiple Kibana instances with a different kibana.index setting per instance, it is considered a multitenant configuration. When using Kibana multitenancy, Reporting needs additional index settings to be customized in each Kibana instance.

  • kibana.index: Configure a unique Kibana index to separate saved objects from other Kibana instances.
  • xpack.task_manager.index: Configure a unique index in Task Manager settings, beginning with .kibana_task_manager, to separate asynchronous tasks from other Kibana instances. Defaults to .kibana_task_manager.
  • xpack.reporting.index: Configure a unique reporting index beginning with .reporting-, to separate report metadata from other Kibana instances. Defaults to .reporting-.

Reporting multitenant exampleedit

Kibana instance A kibana.yml settings:

kibana.index: ".kibana-a"
xpack.task_manager.index: ".kibana_task_manager-a"
xpack.reporting.index: ".reporting-a"

Kibana instance B kibana.yml settings:

kibana.index: ".kibana-b"
xpack.task_manager.index: ".kibana_task_manager-b"
xpack.reporting.index: ".reporting-b"

Configuring multitenancy by changing kibana.index is unsupported starting in 8.0.0. For more details, refer to 8.0 Breaking Changes.

Background job settingsedit

Reporting generates reports in the background and jobs are coordinated using documents in Elasticsearch. Depending on how often you generate reports and the overall number of reports, you might need to change the following settings.

How often the index that stores reporting jobs rolls over to a new index. Valid values are year, month, week, day, and hour. Defaults to week.
xpack.reporting.queue.pollEnabled logo cloud
When true, enables the Kibana instance to poll Elasticsearch for pending jobs and claim them for execution. When false, allows the Kibana instance to only add new jobs to the reporting queue, list jobs, and provide the downloads to completed reports through the UI. This requires a deployment where at least one other Kibana instance in the Elastic cluster has this setting to true. The default is true.

Running multiple instances of Kibana in a cluster for load balancing of reporting requires identical values for xpack.reporting.encryptionKey and, if security is enabled,

Specifies the time that the reporting poller waits between polling the index for any pending Reporting jobs. Can be specified as number of milliseconds. Defaults to 3s.
xpack.reporting.queue.timeout logo cloud
time[How long] each worker has to produce a report. If your machine is slow or under heavy load, you might need to increase this timeout. If a Reporting job execution goes over this time limit, the job is marked as a failure and no download will be available. Can be specified as number of milliseconds. Defaults to 2m.

Capture settingsedit

Reporting works by capturing screenshots from Kibana. The following settings control the capturing process.

xpack.reporting.capture.timeouts.openUrl logo cloud
Specify the time to allow the Reporting browser to wait for the "Loading…​" screen to dismiss and find the initial data for the page. If the time is exceeded, a screenshot is captured showing the current page, and the download link shows a warning message. Can be specified as number of milliseconds. Defaults to 1m.
xpack.reporting.capture.timeouts.waitForElements logo cloud
Specify the time to allow the Reporting browser to wait for all visualization panels to load on the page. If the time is exceeded, a screenshot is captured showing the current page, and the download link shows a warning message. Can be specified as number of milliseconds. Defaults to 30s.
xpack.reporting.capture.timeouts.renderComplete logo cloud
Specify the time to allow the Reporting browser to wait for all visualizations to fetch and render the data. If the time is exceeded, a screenshot is captured showing the current page, and the download link shows a warning message. Can be specified as number of milliseconds. Defaults to 30s.

If any timeouts from xpack.reporting.capture.timeouts.* settings occur when running a report job, Reporting will log the error and try to continue capturing the page with a screenshot. As a result, a download will be available, but there will likely be errors in the visualizations in the report.

xpack.reporting.capture.maxAttempts logo cloud
If capturing a report fails for any reason, Kibana will re-attempt other reporting job, as many times as this setting. Defaults to 3.
Specify the amount of time before taking a screenshot when visualizations are not evented. All visualizations that ship with Kibana are evented, so this setting should not have much effect. If you are seeing empty images instead of visualizations, try increasing this value. Defaults to 3s.
xpack.reporting.capture.browser.type logo cloud
Specifies the browser to use to capture screenshots. This setting exists for backward compatibility. The only valid option is chromium.

Chromium settingsedit

When xpack.reporting.capture.browser.type is set to chromium (default) you can also specify the following settings.

It is recommended that you research the feasibility of enabling unprivileged user namespaces. 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. For more information, refer to Chromium sandbox. Defaults to false for all operating systems except Debian, Red Hat Linux, and CentOS, which use true.
Enables the proxy for Chromium to use. When set to true, you must also specify the xpack.reporting.capture.browser.chromium.proxy.server setting. Defaults to false.
The uri for the proxy server. Providing the username and password for the proxy server via the uri is not supported.
An array of hosts that should not go through the proxy server and should use a direct connection instead. Examples of valid entries are "", "*", "", "".

Network policy settingsedit

To generate PDF reports, Reporting uses the Chromium browser to fully load the Kibana page on the server. This potentially involves sending requests to external hosts. For example, a request might go to an external image server to show a field formatted as an image, or to show an image in a Markdown visualization.

If the Chromium browser is asked to send a request that violates the network policy, Reporting stops processing the page before the request goes out, and the report is marked as a failure. Additional information about the event is in the Kibana server logs.

Kibana installations are not designed to be publicly accessible over the internet. The Reporting network policy and other capabilities of the Elastic Stack security features do not change this condition.

Capturing a screenshot from a Kibana page involves sending out requests for all the linked web assets. For example, a Markdown visualization can show an image from a remote server.
When false, disables the Reporting network policy. Defaults to true.
A policy is specified as an array of objects that describe what to allow or deny based on a host or protocol. If a host or protocol is not specified, the rule matches any host or protocol.

The rule objects are evaluated sequentially from the beginning to the end of the array, and continue until there is a matching rule. If no rules allow a request, the request is denied.

# Only allow requests to
  rules: [ { allow: true, host: "" } ]
# Only allow requests to
  rules: [ { allow: true, host: "", protocol: "https:" } ]

A final allow rule with no host or protocol allows all requests that are not explicitly denied:

# Denies requests from, but anything else is allowed.
  rules: [{ allow: false, host: "", protocol: "http:" }, { allow: true }];

A network policy can be composed of multiple rules:

# Allow any request to but for any other host, https is required
  rules: [
    { allow: true, host: "", protocol: "http:" },
    { allow: true, protocol: "https:" },

The file: protocol is always denied, even if no network policy is configured.

CSV settingsedit

xpack.reporting.csv.maxSizeBytes logo cloud
The maximum byte size of a CSV file before being truncated. This setting exists to prevent large exports from causing performance and storage issues. Can be specified as number of bytes. Defaults to 10mb.

Setting xpack.reporting.csv.maxSizeBytes much larger than the default 10 MB limit has the potential to negatively affect the performance of Kibana and your Elasticsearch cluster. There is no enforced maximum for this setting, but a reasonable maximum value depends on multiple factors:

  • The http.max_content_length setting in Elasticsearch.
  • Network proxies, which are often configured by default to block large requests with a 413 error.
  • The amount of memory available to the Kibana server, which limits the size of CSV data that must be held temporarily.

For information about Kibana memory limits, see using Kibana in a production environment.

Number of documents retrieved from Elasticsearch for each scroll iteration during a CSV export. Defaults to 500.
Amount of time allowed before Kibana cleans the scroll context during a CSV export. Defaults to 30s.
Enables a check that warns you when there’s a potential formula involved in the output (=, -, +, and @ chars). See OWASP: Defaults to true.
xpack.reporting.csv .enablePanelActionDownload
Enables CSV export from a saved search on a dashboard. This action is available in the dashboard panel menu for the saved search. NOTE: This setting exists for backwards compatibility, but is unused and hardcoded to true. CSV export from a saved search on a dashboard is enabled when Reporting is enabled.

Security settingsedit

With Security enabled, Reporting has two forms of access control: each user can only access their own reports, and custom roles determine who has privilege to generate reports. When Reporting is configured with Kibana application privileges, you can control the spaces and applications where users are allowed to generate reports.

The xpack.reporting.roles settings are for a deprecated system of access control in Reporting. Turning off this feature allows API Keys to generate reports, and allows reporting access through Kibana application privileges. We recommend you explicitly turn off reporting’s deprecated access control feature by adding xpack.reporting.roles.enabled: false in kibana.yml. This will enable you to create custom roles that provide application privileges for reporting, as described in granting users access to reporting.

[7.14.0] Deprecated in 7.14.0. The default for this setting will be false in an upcoming version of Kibana. Sets access control to a set of assigned reporting roles, specified by xpack.reporting.roles.allow. Defaults to true.
[7.14.0] Deprecated in 7.14.0. In addition to superusers, specifies the roles that can generate reports using the Elasticsearch role management APIs. Requires xpack.reporting.roles.enabled to be true. Defaults to [ "reporting_user" ].

Kibana server settingsedit

To generate screenshots for PNG and PDF reports, Reporting opens the Kibana web interface using a local connection on the server. In most cases, using a local connection to the Kibana server presents no issue. If you prefer the headless browser to connect to Kibana using a specific hostname, there are a number of settings that allow the headless browser to connect to Kibana through a proxy, rather than directly.

The xpack.reporting.kibanaServer settings are optional. Take caution when editing these settings. Adding these settings can cause the reporting features to fail. If report fail, inspect the server logs. The full Kibana URL that Reporting is attempting to open is logged during report execution.

The port for accessing Kibana.port`>> value.
The protocol for accessing Kibana, typically http or https.
The hostname for accessing Kibana.