Use Kibana in a production environment

How you deploy Kibana largely depends on your use case. If you are the only user, you can run Kibana on your local machine and configure it to point to whatever Elasticsearch instance you want to interact with. Conversely, if you have a large number of heavy Kibana users, you might need to load balance across multiple Kibana instances that are all connected to the same Elasticsearch instance.

While Kibana isn’t terribly resource intensive, we still recommend running Kibana separate from your Elasticsearch data or master nodes. To distribute Kibana traffic across the nodes in your Elasticsearch cluster, you can configure Kibana to use a list of Elasticsearch hosts.

To serve multiple Kibana installations behind a load balancer, you must change the configuration. See Configuring Kibana for details on each setting.

These settings must be unique across each Kibana instance:

server.uuid // if not provided, this is autogenerated
server.name
path.data
pid.file
server.port

When using a file appender, the target file must also be unique:

logging:
  appenders:
    default:
      type: file
      fileName: /unique/path/per/instance

Settings that must be the same:

xpack.security.encryptionKey //decrypting session information
xpack.security.authc.* // authentication configuration
xpack.security.session.* // session configuration
xpack.reporting.encryptionKey //decrypting reports
xpack.encryptedSavedObjects.encryptionKey // decrypting saved objects
xpack.encryptedSavedObjects.keyRotation.decryptionOnlyKeys // saved objects encryption key rotation, if any

Separate configuration files can be used from the command line by using the -c flag:

bin/kibana -c config/instance1.yml
bin/kibana -c config/instance2.yml

To access multiple load-balanced Kibana clusters from the same browser, explicitly set xpack.security.cookieName to the same value in the Kibana configuration of each Kibana instance.

Each Kibana cluster must have a different value of xpack.security.cookieName.

This avoids conflicts between cookies from the different Kibana instances.

This will achieve seamless high availability and keep the session active in case of failure from the currently used instance.

Kibana can be configured to connect to multiple Elasticsearch nodes in the same cluster. In situations where a node becomes unavailable, Kibana will transparently connect to an available node and continue operating. Requests to available hosts will be routed in a round robin fashion.

In kibana.yml:

elasticsearch.hosts:
  - http://elasticsearch1:9200
  - http://elasticsearch2:9200

Related configurations include elasticsearch.sniffInterval, elasticsearch.sniffOnStart, and elasticsearch.sniffOnConnectionFault. These can be used to automatically update the list of hosts as a cluster is resized. Parameters can be found on the settings page.

Kibana has a default memory limit that scales based on total memory available. In some scenarios, such as large reporting jobs, it may make sense to tweak limits to meet more specific requirements.

A limit can be defined by setting --max-old-space-size in the node.options config file found inside the kibana/config folder or any other folder configured with the environment variable KBN_PATH_CONF. For example, in the Debian-based system, the folder is /etc/kibana.

The option accepts a limit in MB:

--max-old-space-size=2048

Starting in 8.10.0, Kibana has upgraded its runtime environment, Node.js, from version 16 to version 18 and with it the underlying version of OpenSSL to version 3. Algorithms deemed legacy by OpenSSL 3 have been re-enabled to avoid potential breaking changes in a minor version release of Kibana. If SSL certificates configured for Kibana are not using any of the legacy algorithms mentioned in the OpenSSL legacy provider documentation, we recommend disabling this setting by removing --openssl-legacy-provider in the node.options config file.