[Docs/Reporting] Include working config example for multiple kibana.index (#25410) (#25812)

* [Docs] Include working config example for multiple kibana.index in the cluster

* updates

docs/reporting/configuring-reporting.asciidoc

@@ -2,12 +2,22 @@
 [[configuring-reporting]]
 == Configuring Reporting
 
-NOTE: If you use a reverse-proxy (NGINX, Apache, etc.) to access Kibana, you need
-to configure the <<reporting-kibana-server-settings, Kibana server settings>>
+You can configure settings in `kibana.yml` to control how {reporting}
+communicates with the Kibana server, manages background jobs, and captures
+screenshots. See <<reporting-settings-kb, Reporting Settings>> for the complete
+list of settings.
+
+=== Encryption Keys for Multiple Kibana Instances
 
 By default, a new encryption key is generated for {reporting} each time
-you start Kibana. This means any pending reports will fail if you
-restart Kibana.
+you start Kibana. This means if a static encryption key is not persisted in the
+Kibana configuration, any pending reports will fail when you restart Kibana.
+
+If you are load balancing across multiple Kibana instances, they need to have
+the same reporting encryption key. Otherwise, report generation will fail if a
+report is queued through one instance and another instance picks up the job
+from the report queue. The other instance will not be able to decrypt the
+reporting job metadata.
 
 To set a static encryption key for reporting, set the
 `xpack.reporting.encryptionKey` property in the `kibana.yml`
@@ -18,14 +28,44 @@ configuration file. You can use any text string as the encryption key.
 xpack.reporting.encryptionKey: "something_secret"
 --------------------------------------------------------------------------------
 
-NOTE: If you are load balancing across multiple Kibana instances, they need
-to have the same reporting encryption key. Otherwise, report generation
-will fail if a report is requested through one instance and another instance
-picks up the job from the report queue.
+=== Reporting Indices for Multiple Kibana Workspaces
 
-You can also configure settings in `kibana.yml` to control how {reporting}
-communicates with the Kibana server, manages background jobs, and captures
-screenshots. See <<reporting-settings-kb, Reporting Settings>> for the complete
-list of settings.
+If you divide workspaces in an Elastic cluster using multiple Kibana instances
+with a different `kibana.index` setting per instance, you must set a unique `xpack.reporting.index`
+setting per `kibana.index`. Otherwise, report generation will periodically fail
+if a report is queued through an instance with one `kibana.index` setting, and
+an instance with a different `kibana.index` attempts to claim the job.
+
+Kibana instance A:
+[source,yaml]
+--------------------------------------------------------------------------------
+kibana.index: ".kibana-a"
+xpack.reporting.index: ".reporting-a"
+xpack.reporting.encryptionKey: "something_secret"
+--------------------------------------------------------------------------------
+
+Kibana instance B:
+[source,yaml]
+--------------------------------------------------------------------------------
+kibana.index: ".kibana-b"
+xpack.reporting.index: ".reporting-b"
+xpack.reporting.encryptionKey: "something_secret"
+--------------------------------------------------------------------------------
+
+NOTE: If security is enabled, the `xpack.reporting.index` setting should begin
+with `.reporting-` in order for the `kibana_system` role to have the necessary
+privileges over the index.
+
+=== Using Reverse Proxies
+
+If your Kibana instance requires a reverse-proxy (NGINX, Apache, etc.) for
+access, because of rewrite rules or special headers being added by the proxy,
+then you need to configure the `xpack.reporting.kibanaServer` settings to make
+the headless browser process connect to the proxy in <<reporting-kibana-server-settings, Kibana server settings>>.
+
+NOTE: A headless browser runs on the Kibana server to open a Kibana page for
+capturing screenshots. Configuring the `xpack.reporting.kibanaServer` settings
+to point to a proxy host requires that the Kibana server has network access to
+the proxy.
 
 include::{kib-repo-dir}/security/reporting.asciidoc[]

docs/settings/reporting-settings.asciidoc

@@ -18,9 +18,9 @@ You can configure `xpack.reporting` settings in your `kibana.yml` to:
 Set to `false` to disable {reporting}.
 
 `xpack.reporting.encryptionKey`::
-Set to any text string. By default, Kibana generates a random key when it starts,
-which causes pending reports to fail on restart. Configure this setting to use
-the same key across restarts.
+Set to any text string. By default, Kibana will generate a random key when it
+starts, which will cause pending reports to fail after restart. Configure this
+setting to preserve the same key across multiple restarts and multiple instances of Kibana.
 
 [float]
 [[reporting-kibana-server-settings]]
@@ -39,6 +39,9 @@ The protocol for accessing Kibana, typically `http` or `https`.
 `xpack.reporting.kibanaServer.hostname`::
 The hostname for accessing Kibana, if different from the `server.name` value.
 
+NOTE: Configuring the `xpack.reporting.kibanaServer` settings to point to a
+proxy host requires that the Kibana server has network access to the proxy.
+
 [float]
 [[reporting-job-queue-settings]]
 ==== Background Job Settings
@@ -131,9 +134,10 @@ Defaults to `10485760` (10mB)
 ==== Advanced Settings
 
 `xpack.reporting.index`::
-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.
-Defaults to `.reporting`
+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. Configure this to a unique value, beginning with `.reporting-`, for every
+Kibana instance that has a unique `kibana.index` setting. Defaults to `.reporting`
 
 `xpack.reporting.roles.allow`::
 Specifies the roles in addition to superusers that can use reporting.