diff --git a/docs/static/monitoring/collectors.asciidoc b/docs/static/monitoring/collectors.asciidoc
index 30a373f24bb..b8b70f4f28f 100644
--- a/docs/static/monitoring/collectors.asciidoc
+++ b/docs/static/monitoring/collectors.asciidoc
@@ -37,7 +37,7 @@ in its isolated monitoring pipeline. The Logstash output then sends the data.
 
 The collection interval can be configured dynamically and you can also disable 
 data collection. For more information about the configuration options for the 
-collectors, see <<monitoring-settings>>.
+collectors, see <<monitoring-settings-legacy>>.
 
 WARNING: Unlike {monitoring} for {es} and {kib}, there is no 
 `xpack.monitoring.collection.enabled` setting on Logstash. You must use the 
diff --git a/docs/static/monitoring/monitoring-internal-legacy.asciidoc b/docs/static/monitoring/monitoring-internal-legacy.asciidoc
new file mode 100644
index 00000000000..da02859185e
--- /dev/null
+++ b/docs/static/monitoring/monitoring-internal-legacy.asciidoc
@@ -0,0 +1,142 @@
+[role="xpack"]
+[[monitoring-internal-collection-legacy]]
+=== Collect {ls} monitoring data using legacy internal collectors
+++++
+<titleabbrev>Legacy internal collection (deprecated)</titleabbrev>
+++++
+
+Monitoring {ls} with legacy internal collection uses these components:
+
+* <<logstash-monitoring-collectors,Collectors>>
+* <<logstash-monitoring-output,Output>>
+
+These pieces live outside of the default Logstash pipeline in a dedicated monitoring
+pipeline. This configuration ensures that all data and processing has a minimal
+impact on ordinary Logstash processing. Existing Logstash features, such as the
+<<plugins-outputs-elasticsearch,`elasticsearch` output>>, can be reused to
+benefit from its retry policies. 
+
+NOTE: The `elasticsearch` output that is used by {monitoring} for Logstash is 
+configured exclusively via settings found in `logstash.yml`. It is not 
+configured by using anything from the Logstash configurations that might also be 
+using their own separate `elasticsearch` outputs.
+
+The {es} cluster that is configured for use with {monitoring} for Logstash is 
+expected to be the production cluster. This configuration enables the production 
+{es} cluster to add metadata (for example, its cluster UUID) to the Logstash
+monitoring data then route it to the monitoring clusters. For more information 
+about typical monitoring architectures, see 
+{ref}/how-monitoring-works.html[How monitoring works] in the {ref}[Elasticsearch Reference]. 
+
+include::collectors.asciidoc[]
+include::monitoring-output.asciidoc[]
+
+
+[[configure-internal-collectors]]
+==== Configure {ls} monitoring with internal collectors
+++++
+<titleabbrev>Configure internal collection</titleabbrev>
+++++
+
+To monitor Logstash nodes:
+
+. Specify where to send monitoring data. This cluster is often referred to as
+the _production cluster_. For examples of typical monitoring architectures, see
+{ref}/how-monitoring-works.html[How monitoring works].
++
+--
+IMPORTANT: To visualize Logstash as part of the Elastic Stack (as shown in Step
+6), send metrics to your _production_ cluster. Sending metrics to a dedicated
+monitoring cluster will show the Logstash metrics under the _monitoring_ cluster.
+
+--
+
+. Verify that the `xpack.monitoring.collection.enabled` setting is `true` on the
+production cluster. If that setting is `false`, the collection of monitoring data
+is disabled in {es} and data is ignored from all other sources.
+
+. Configure your Logstash nodes to send metrics by setting the
+`xpack.monitoring.elasticsearch.hosts` in `logstash.yml`. If {security-features}
+are enabled, you also need to specify the credentials for the
+{ref}/built-in-users.html[built-in `logstash_system` user]. For more information
+about these settings, see <<monitoring-settings-legacy>>.
++
+--
+[source,yaml]
+--------------------------------------------------
+xpack.monitoring.elasticsearch.hosts: ["http://es-prod-node-1:9200", "http://es-prod-node-2:9200"] <1>
+xpack.monitoring.elasticsearch.username: "logstash_system" <2>
+xpack.monitoring.elasticsearch.password: "changeme"
+--------------------------------------------------
+
+<1> If SSL/TLS is enabled on the production cluster, you must
+connect through HTTPS. As of v5.2.1, you can specify multiple
+Elasticsearch hosts as an array as well as specifying a single
+host as a string. If multiple URLs are specified, Logstash
+can round-robin requests to these production nodes.
+<2> If {security-features} are disabled on the production cluster, you can omit
+these  `username` and `password` settings. 
+--
+
+. If SSL/TLS is enabled on the production {es} cluster, specify the trusted
+CA certificates that will be used to verify the identity of the nodes
+in the cluster.
++
+--
+To add a CA certificate to a Logstash node's trusted certificates, you
+can specify the location of the PEM encoded certificate with the
+`certificate_authority` setting:
+
+[source,yaml]
+--------------------------------------------------
+xpack.monitoring.elasticsearch.ssl.certificate_authority: /path/to/ca.crt
+--------------------------------------------------
+
+Alternatively, you can configure trusted certificates using a truststore
+(a Java Keystore file that contains the certificates):
+
+[source,yaml]
+--------------------------------------------------
+xpack.monitoring.elasticsearch.ssl.truststore.path: /path/to/file
+xpack.monitoring.elasticsearch.ssl.truststore.password: password
+--------------------------------------------------
+
+Also, optionally, you can set up client certificate using a keystore
+(a Java Keystore file that contains the certificate):
+
+[source,yaml]
+--------------------------------------------------
+xpack.monitoring.elasticsearch.ssl.keystore.path: /path/to/file
+xpack.monitoring.elasticsearch.ssl.keystore.password: password
+--------------------------------------------------
+
+Set sniffing to `true` to enable discovery of other nodes of the {es} cluster.
+It defaults to `false`.
+
+[source,yaml]
+--------------------------------------------------
+xpack.monitoring.elasticsearch.sniffing: false
+--------------------------------------------------
+
+--
+
+. Restart your Logstash nodes.
+
+. To verify your {monitoring} configuration, point your web browser at your {kib}
+host, and select **Monitoring** from the side navigation. Metrics reported from
+your Logstash nodes should be visible in the Logstash section. When security is
+enabled, to view the monitoring dashboards you must log in to {kib} as a user
+who has the `kibana_user` and `monitoring_user` roles.
++
+image::images/monitoring-ui.png["Monitoring",link="monitoring/images/monitoring-ui.png"]
+
+[float]
+[[monitoring-upgraded-logstash]]
+===== Re-enabling Logstash Monitoring After Upgrading
+
+When upgrading from older versions of {xpack}, the built-in `logstash_system`
+user is disabled for security reasons. To resume monitoring,
+change the password and re-enable the logstash_system user.
+
+include::../settings/monitoring-settings-legacy.asciidoc[]
+
diff --git a/docs/static/monitoring/monitoring-internal.asciidoc b/docs/static/monitoring/monitoring-internal.asciidoc
index c58fffadbc1..80b1d4e11d4 100644
--- a/docs/static/monitoring/monitoring-internal.asciidoc
+++ b/docs/static/monitoring/monitoring-internal.asciidoc
@@ -2,143 +2,103 @@
 [[monitoring-internal-collection]]
 === Collect {ls} monitoring data using internal collectors
 ++++
-<titleabbrev>Internal collection (deprecated)</titleabbrev>
+<titleabbrev>Internal collection</titleabbrev>
 ++++
 
-deprecated[7.7.0]
+Use internal collectors to send {ls} monitoring data directly to your
+monitoring cluster.
 
-Using internal collectors for {ls} {monitoring} these components:
+As an alternative to internal collection, you can use
+<<monitoring-with-metricbeat>>. When you use internal collection
+instead of {metricbeat}, you have fewer pieces of software to install
+and maintain.
 
-* <<logstash-monitoring-collectors,Collectors>>
-* <<logstash-monitoring-output,Output>>
+To learn about monitoring in general, see 
+{ref}/monitor-elasticsearch-cluster.html[Monitor a cluster]. 
 
-These pieces live outside of the default Logstash pipeline in a dedicated monitoring
-pipeline. This configuration ensures that all data and processing has a minimal
-impact on ordinary Logstash processing. Existing Logstash features, such as the
-<<plugins-outputs-elasticsearch,`elasticsearch` output>>, can be reused to
-benefit from its retry policies. 
+. Create an API key or user that has appropriate authority to send system-level monitoring
+data to {es}. For example, you can use the built-in +{beat_monitoring_user}+ user or
+assign the built-in +{beat_monitoring_user}+ role to another user. For more
+information on the required privileges, see <<ls-monitoring-user>>.
+For more information on how to use API keys, see TBD.
 
-NOTE: The `elasticsearch` output that is used by {monitoring} for Logstash is 
-configured exclusively via settings found in `logstash.yml`. It is not 
-configured by using anything from the Logstash configurations that might also be 
-using their own separate `elasticsearch` outputs.
+TODO: LS API keys
 
-The {es} cluster that is configured for use with {monitoring} for Logstash is 
-expected to be the production cluster. This configuration enables the production 
-{es} cluster to add metadata (for example, its cluster UUID) to the Logstash
-monitoring data then route it to the monitoring clusters. For more information 
-about typical monitoring architectures, see 
-{ref}/how-monitoring-works.html[How monitoring works] in the {ref}[Elasticsearch Reference]. 
-
-include::collectors.asciidoc[]
-include::monitoring-output.asciidoc[]
-
-
-[[configure-internal-collectors]]
-==== Configure {ls} monitoring with internal collectors
-++++
-<titleabbrev>Configure internal collection</titleabbrev>
-++++
-
-To monitor Logstash nodes:
-
-. Specify where to send monitoring data. This cluster is often referred to as
-the _production cluster_. For examples of typical monitoring architectures, see
-{ref}/how-monitoring-works.html[How monitoring works].
+. Add the `monitoring` settings in the {beatname_uc} configuration file. If you
+configured the {es} output and want to send {beatname_uc} monitoring events to
+the same {es} cluster, specify the following minimal configuration:
 +
---
-IMPORTANT: To visualize Logstash as part of the Elastic Stack (as shown in Step
-6), send metrics to your _production_ cluster. Sending metrics to a dedicated
-monitoring cluster will show the Logstash metrics under the _monitoring_ cluster.
-
---
-
-. Verify that the `xpack.monitoring.collection.enabled` setting is `true` on the
-production cluster. If that setting is `false`, the collection of monitoring data
-is disabled in {es} and data is ignored from all other sources.
-
-. Configure your Logstash nodes to send metrics by setting the
-`xpack.monitoring.elasticsearch.hosts` in `logstash.yml`. If {security} is
-enabled, you also need to specify the credentials for the
-{ref}/built-in-users.html[built-in `logstash_system` user]. For more
-information about these settings, see <<monitoring-settings>>.
+["source","yml",subs="attributes"]
+--------------------
+monitoring:
+  enabled: true
+  elasticsearch:
+    api_key:  id:api_key <1>
+    username: {beat_monitoring_user}
+    password: somepassword
+--------------------
+<1> Specify one of `api_key` or `username`/`password`.
 +
---
-[source,yaml]
---------------------------------------------------
-xpack.monitoring.elasticsearch.hosts: ["http://es-prod-node-1:9200", "http://es-prod-node-2:9200"] <1>
-xpack.monitoring.elasticsearch.username: "logstash_system" <2>
-xpack.monitoring.elasticsearch.password: "changeme"
---------------------------------------------------
-
-<1> If SSL/TLS is enabled on the production cluster, you must
-connect through HTTPS. As of v5.2.1, you can specify multiple
-Elasticsearch hosts as an array as well as specifying a single
-host as a string. If multiple URLs are specified, Logstash
-can round-robin requests to these production nodes.
-<2> If {security} is disabled on the production cluster, you can omit these 
-`username` and `password` settings. 
---
-
-. If SSL/TLS is enabled on the production {es} cluster, specify the trusted
-CA certificates that will be used to verify the identity of the nodes
-in the cluster.
+If you want to send monitoring events to an https://cloud.elastic.co/[{ecloud}]
+monitoring cluster, you can use two simpler settings. When defined, these settings
+overwrite settings from other parts in the configuration. For example:
 +
---
-To add a CA certificate to a Logstash node's trusted certificates, you
-can specify the location of the PEM encoded certificate with the
-`certificate_authority` setting:
-
 [source,yaml]
---------------------------------------------------
-xpack.monitoring.elasticsearch.ssl.certificate_authority: /path/to/ca.crt
---------------------------------------------------
-
-Alternatively, you can configure trusted certificates using a truststore
-(a Java Keystore file that contains the certificates):
-
-[source,yaml]
---------------------------------------------------
-xpack.monitoring.elasticsearch.ssl.truststore.path: /path/to/file
-xpack.monitoring.elasticsearch.ssl.truststore.password: password
---------------------------------------------------
-
-Also, optionally, you can set up client certificate using a keystore
-(a Java Keystore file that contains the certificate):
-
-[source,yaml]
---------------------------------------------------
-xpack.monitoring.elasticsearch.ssl.keystore.path: /path/to/file
-xpack.monitoring.elasticsearch.ssl.keystore.password: password
---------------------------------------------------
-
-Set sniffing to `true` to enable discovery of other nodes of the {es} cluster.
-It defaults to `false`.
-
+--------------------
+monitoring:
+  enabled: true
+  cloud.id: 'staging:dXMtZWFzdC0xLmF3cy5mb3VuZC5pbyRjZWM2ZjI2MWE3NGJmMjRjZTMzYmI4ODExYjg0Mjk0ZiRjNmMyY2E2ZDA0MjI0OWFmMGNjN2Q3YTllOTYyNTc0Mw=='
+  cloud.auth: 'elastic:{pwd}'
+--------------------
++
+If you want to send monitoring events to a separate {es} cluster
+(referred to as the _monitoring cluster_), you must specify additional
+configuration options. For example:
++
+["source","yml",subs="attributes"]
+--------------------
+monitoring:
+  enabled: true
+  cluster_uuid: PRODUCTION_ES_CLUSTER_UUID <1>
+  elasticsearch:
+    hosts: ["https://example.com:9200", "https://example2.com:9200"] <2>
+    api_key:  id:api_key <3>
+    username: {beat_monitoring_user}
+    password: somepassword
+--------------------
+<1> This setting identifies the {es} cluster under which the
+monitoring data for this {beatname_uc} instance will appear in the
+Stack Monitoring UI. To get a cluster's `cluster_uuid`,
+call the `GET /` API against that cluster.
+<2> This setting identifies the hosts and port numbers of {es} nodes
+that are part of the monitoring cluster.
+<3> Specify one of `api_key` or `username`/`password`.
++
+If you want to use PKI authentication to send monitoring events to
+{es}, you must specify a different set of configuration options. For
+example:
++
 [source,yaml]
---------------------------------------------------
-xpack.monitoring.elasticsearch.sniffing: false
---------------------------------------------------
-
---
-
-. Restart your Logstash nodes.
-
-. To verify your {monitoring} configuration, point your web browser at your {kib}
-host, and select **Monitoring** from the side navigation. Metrics reported from
-your Logstash nodes should be visible in the Logstash section. When security is
-enabled, to view the monitoring dashboards you must log in to {kib} as a user
-who has the `kibana_user` and `monitoring_user` roles.
+--------------------
+monitoring:
+  enabled: true
+  cluster_uuid: PRODUCTION_ES_CLUSTER_UUID
+  elasticsearch:
+    hosts: ["https://example.com:9200", "https://example2.com:9200"]
+    username: ""
+    ssl:
+      ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
+      ssl.certificate: "/etc/pki/client/cert.pem"
+      ssl.key: "/etc/pki/client/cert.key"
+--------------------
 +
-image::images/monitoring-ui.png["Monitoring",link="monitoring/images/monitoring-ui.png"]
+You must specify the `username` as `""` explicitly so that
+the username from the client certificate (`CN`) is used. See
+TBD for more information about SSL settings.
 
-[float]
-[[monitoring-upgraded-logstash]]
-===== Re-enabling Logstash Monitoring After Upgrading
 
-When upgrading from older versions of {xpack}, the built-in `logstash_system`
-user is disabled for security reasons. To resume monitoring,
-change the password and re-enable the logstash_system user.
+. Start {ls}.
 
-include::../settings/monitoring-settings.asciidoc[]
+. {kibana-ref}/monitoring-data.html[View the monitoring data in {kib}]. 
 
+include::../settings/monitoring-settings.asciidoc[]
diff --git a/docs/static/monitoring/monitoring-mb.asciidoc b/docs/static/monitoring/monitoring-mb.asciidoc
index d267211b115..9e334dc6cc1 100644
--- a/docs/static/monitoring/monitoring-mb.asciidoc
+++ b/docs/static/monitoring/monitoring-mb.asciidoc
@@ -6,16 +6,16 @@
 <titleabbrev>{metricbeat} collection</titleabbrev>
 ++++
 
-In 7.3 and later, you can use {metricbeat} to collect data about {ls} 
-and ship it to the monitoring cluster, rather than routing it through the 
-production cluster as described in <<monitoring-internal-collection>>.
+You can use {metricbeat} to collect data about {ls} and ship it to the
+monitoring cluster. The benefit of Metricbeat collection is that the monitoring
+agent remains active even if the {ls} instance does not.
 
 //NOTE: The tagged regions are re-used in the Stack Overview.
 
 To collect and ship monitoring data:
 
 . <<disable-default,Disable default collection of monitoring metrics>>
-. <<define-cluster__uuid,Specify optionally the target `cluster_uuid`>>
+. <<define-cluster__uuid,Specify the target `cluster_uuid` (optional)>>
 . <<configure-metricbeat,Install and configure {metricbeat} to collect monitoring data>>
 
 [float]
diff --git a/docs/static/monitoring/monitoring-output.asciidoc b/docs/static/monitoring/monitoring-output.asciidoc
index 08ce60ecf26..851a626308a 100644
--- a/docs/static/monitoring/monitoring-output.asciidoc
+++ b/docs/static/monitoring/monitoring-output.asciidoc
@@ -44,4 +44,4 @@ environments to production environments, where you often have dedicated
 monitoring clusters.
 
 For more information about the configuration options for the output, see 
-<<monitoring-settings>>.
\ No newline at end of file
+<<monitoring-settings-legacy>>.
\ No newline at end of file
diff --git a/docs/static/monitoring/monitoring-overview.asciidoc b/docs/static/monitoring/monitoring-overview.asciidoc
index 1764aef29c6..35ab5ac2b08 100644
--- a/docs/static/monitoring/monitoring-overview.asciidoc
+++ b/docs/static/monitoring/monitoring-overview.asciidoc
@@ -1,27 +1,37 @@
 [role="xpack"]
 [[configuring-logstash]]
-== Monitoring {ls} with {xpack}
+== Monitoring {ls}
 
 Use the {stack} {monitor-features} to gain insight into the health of
 {ls} instances running in your environment.
 
 For an introduction to monitoring your Elastic stack, see
-{ref}/monitor-elasticsearch-cluster.html[Monitoring a cluster].
-
+{ref}/monitor-elasticsearch-cluster.html[Monitoring a cluster] in the
+{ref}[Elasticsearch Reference].
 
 [float]
 [[configuring-logstash-xpack]]
-=== Configuring {xpack} monitoring for {ls}
+=== Configuring monitoring for {ls}
 
 Make sure monitoring is enabled on your {es} cluster. Then configure *one* of
 these methods to collect {ls} metrics:
 
-* <<monitoring-with-metricbeat, {metricbeat} collection>>
-* <<monitoring-internal-collection,Internal collection (deprecated)>>
+* <<monitoring-with-metricbeat, {metricbeat} collection>>. Metricbeat collects
+monitoring data from your {ls} instance and sends it directly to your monitoring
+cluster. The benefit of Metricbeat collection is that the monitoring
+agent remains active even if the {ls} instance does not.
+
+* <<monitoring-internal-collection,Internal collection>>. Internal collectors send
+monitoring data directly to your monitoring cluster. The benefit of internal
+collection is that you have fewer pieces of software to install and maintain.
+
+* <<monitoring-internal-collection-legacy,Legacy internal collection>>. Legacy
+internal collectors send monitoring data to your production cluster.
 
 
 include::monitoring-mb.asciidoc[]
 include::monitoring-internal.asciidoc[]
+include::monitoring-internal-legacy.asciidoc[]
 include::monitoring-ui.asciidoc[]
 include::pipeline-viewer.asciidoc[]
 include::troubleshooting.asciidoc[]
diff --git a/docs/static/settings/monitoring-settings-legacy.asciidoc b/docs/static/settings/monitoring-settings-legacy.asciidoc
new file mode 100644
index 00000000000..62234ec2a78
--- /dev/null
+++ b/docs/static/settings/monitoring-settings-legacy.asciidoc
@@ -0,0 +1,106 @@
+[role="xpack"]
+[[monitoring-settings-legacy]]
+==== Monitoring settings for legacy internal collection
+++++
+<titleabbrev>Monitoring Settings</titleabbrev>
+++++
+
+You can set the following `xpack.monitoring` settings in `logstash.yml` to
+control how monitoring data is collected from your Logstash nodes. However, the
+defaults work best in most circumstances. For more information about configuring
+Logstash, see <<logstash-settings-file>>.
+
+
+[[monitoring-general-settings-legacy]]
+===== General monitoring settings
+
+`xpack.monitoring.enabled`::
+
+Monitoring is disabled by default. Set to `true` to enable {xpack} monitoring.
+
+`xpack.monitoring.elasticsearch.hosts`::
+
+The {es} instances that you want to ship your Logstash metrics to. This might be
+the same {es} instance specified in the `outputs` section in your Logstash
+configuration, or a different one. This is *not* the URL of your dedicated
+monitoring cluster. Even if you are using a dedicated monitoring cluster, the
+Logstash metrics must be routed through your production cluster. You can specify
+a single host as a string, or specify multiple hosts as an array. Defaults to
+`http://localhost:9200`.
+
+NOTE: If your Elasticsearch cluster is configured with dedicated master-eliglble
+nodes, Logstash metrics should _not_ be routed to these nodes, as doing so can
+create resource contention and impact the stability of the Elasticsearch
+cluster. Therefore, do not include such nodes in
+`xpack.monitoring.elasticsearch.hosts`.
+
+`xpack.monitoring.elasticsearch.username` and `xpack.monitoring.elasticsearch.password`::
+
+If your {es} is protected with basic authentication, these settings provide the
+username and password that the Logstash instance uses to authenticate for
+shipping monitoring data.
+
+
+[[monitoring-collection-settings-legacy]]
+===== Monitoring collection settings
+
+`xpack.monitoring.collection.interval`::
+
+Controls how often data samples are collected and shipped on the Logstash side.
+Defaults to `10s`. If you modify the collection interval, set the 
+`xpack.monitoring.min_interval_seconds` option in `kibana.yml` to the same value.
+
+
+[[monitoring-ssl-settings-legacy]]
+===== {monitoring} TLS/SSL settings
+
+You can configure the following Transport Layer Security (TLS) or
+Secure Sockets Layer (SSL) settings. For more information, see 
+<<ls-monitoring-user>>.
+
+`xpack.monitoring.elasticsearch.ssl.certificate_authority`::
+
+Optional setting that enables you to specify a path to the `.pem` file for the
+certificate authority for your {es} instance.
+
+`xpack.monitoring.elasticsearch.ssl.truststore.path`::
+
+Optional settings that provide the paths to the Java keystore (JKS) to validate
+the server’s certificate.
+
+`xpack.monitoring.elasticsearch.ssl.truststore.password`::
+
+Optional settings that provide the password to the truststore.
+
+`xpack.monitoring.elasticsearch.ssl.keystore.path`::
+
+Optional settings that provide the paths to the Java keystore (JKS) to validate
+the client’s certificate.
+
+`xpack.monitoring.elasticsearch.ssl.keystore.password`::
+
+Optional settings that provide the password to the keystore.
+
+`xpack.monitoring.elasticsearch.ssl.verification_mode`::
+
+Option to validate the server’s certificate. Defaults to `certificate`. To
+disable, set to `none`. Disabling this severely compromises security.
+
+[[monitoring-additional-settings-legacy]]
+===== Additional settings
+
+`xpack.monitoring.elasticsearch.cloud_id`::
+
+If you're using {es} in {ecloud}, you should specify the identifier here.
+This setting is an alternative to `xpack.monitoring.elasticsearch.hosts`.
+If `cloud_id` is configured, `xpack.monitoring.elasticsearch.hosts` should not be used.
+The {es} instances that you want to ship your Logstash metrics to. This might be
+the same {es} instance specified in the `outputs` section in your Logstash
+configuration, or a different one.
+
+`xpack.monitoring.elasticsearch.cloud_auth`::
+
+If you're using {es} in {ecloud}, you can set your auth credentials here.
+This setting is an alternative to both `xpack.monitoring.elasticsearch.username`
+and `xpack.monitoring.elasticsearch.password`. If `cloud_auth` is configured,
+those settings should not be used.
diff --git a/docs/static/settings/monitoring-settings.asciidoc b/docs/static/settings/monitoring-settings.asciidoc
index 4309ad89df4..a85317adb65 100644
--- a/docs/static/settings/monitoring-settings.asciidoc
+++ b/docs/static/settings/monitoring-settings.asciidoc
@@ -5,7 +5,7 @@
 <titleabbrev>Monitoring Settings</titleabbrev>
 ++++
 
-You can set the following `xpack.monitoring` settings in `logstash.yml` to
+You can set the following `monitoring` settings in `logstash.yml` to
 control how monitoring data is collected from your Logstash nodes. However, the
 defaults work best in most circumstances. For more information about configuring
 Logstash, see <<logstash-settings-file>>.
@@ -14,11 +14,16 @@ Logstash, see <<logstash-settings-file>>.
 [[monitoring-general-settings]]
 ===== General monitoring settings
 
-`xpack.monitoring.enabled`::
+`monitoring.enabled`::
 
-Monitoring is disabled by default. Set to `true` to enable {xpack} monitoring.
+Monitoring is disabled by default. Set to `true` to enable monitoring.
 
-`xpack.monitoring.elasticsearch.hosts`::
+`monitoring.cluster_uuid`::
+
+The universally unique identifier (UUID) for the monitoring cluster.
+Defaults to `elasticsearch_cluster_uuid`.
+
+`monitoring.elasticsearch.hosts`::
 
 The {es} instances that you want to ship your Logstash metrics to. This might be
 the same {es} instance specified in the `outputs` section in your Logstash
@@ -32,9 +37,9 @@ NOTE: If your Elasticsearch cluster is configured with dedicated master-eliglble
 nodes, Logstash metrics should _not_ be routed to these nodes, as doing so can
 create resource contention and impact the stability of the Elasticsearch
 cluster. Therefore, do not include such nodes in
-`xpack.monitoring.elasticsearch.hosts`.
+`monitoring.elasticsearch.hosts`.
 
-`xpack.monitoring.elasticsearch.username` and `xpack.monitoring.elasticsearch.password`::
+`monitoring.elasticsearch.username` and `monitoring.elasticsearch.password`::
 
 If your {es} is protected with basic authentication, these settings provide the
 username and password that the Logstash instance uses to authenticate for
@@ -44,58 +49,76 @@ shipping monitoring data.
 [[monitoring-collection-settings]]
 ===== Monitoring collection settings
 
-`xpack.monitoring.collection.interval`::
+`monitoring.collection.pipeline.details.enabled`::
 
-Controls how often data samples are collected and shipped on the Logstash side.
-Defaults to `10s`. If you modify the collection interval, set the 
-`xpack.monitoring.min_interval_seconds` option in `kibana.yml` to the same value.
+ToDo: Add description
 
+Defaults to `true`.
+
+`monitoring.collection.interval`::
+
+Controls how often data samples are collected and shipped on the Logstash side.
+Defaults to `10s`. If you modify the collection interval, add the
+`monitoring.min_interval_seconds` option to `kibana.yml`, and set it to the same
+value.
 
 [[monitoring-ssl-settings]]
-===== {monitoring} TLS/SSL settings
+===== Monitoring TLS/SSL settings
 
 You can configure the following Transport Layer Security (TLS) or
 Secure Sockets Layer (SSL) settings. For more information, see 
 <<ls-monitoring-user>>.
 
-`xpack.monitoring.elasticsearch.ssl.certificate_authority`::
+`monitoring.elasticsearch.ssl.certificate_authority`::
 
 Optional setting that enables you to specify a path to the `.pem` file for the
 certificate authority for your {es} instance.
 
-`xpack.monitoring.elasticsearch.ssl.truststore.path`::
+`monitoring.elasticsearch.ssl.truststore.path`::
 
 Optional settings that provide the paths to the Java keystore (JKS) to validate
 the server’s certificate.
 
-`xpack.monitoring.elasticsearch.ssl.truststore.password`::
+`monitoring.elasticsearch.ssl.truststore.password`::
 
 Optional settings that provide the password to the truststore.
 
-`xpack.monitoring.elasticsearch.ssl.keystore.path`::
+`monitoring.elasticsearch.ssl.keystore.path`::
 
 Optional settings that provide the paths to the Java keystore (JKS) to validate
 the client’s certificate.
 
-`xpack.monitoring.elasticsearch.ssl.keystore.password`::
+`monitoring.elasticsearch.ssl.keystore.password`::
 
 Optional settings that provide the password to the keystore.
 
+`monitoring.elasticsearch.ssl.verification_mode`::
+
+Option to validate the server’s certificate. Defaults to `certificate`. To
+disable, set to `none`. Disabling this severely compromises security.
+
+`monitoring.elasticsearch.sniffing`::
+
+ToDo: Add description 
+
+Defaults to `false`.
+
+
 [[monitoring-additional-settings]]
 ===== Additional settings
 
-`xpack.monitoring.elasticsearch.cloud_id`::
+`monitoring.elasticsearch.cloud_id`::
 
 If you're using {es} in {ecloud}, you should specify the identifier here.
-This setting is an alternative to `xpack.monitoring.elasticsearch.hosts`.
-If `cloud_id` is configured, `xpack.monitoring.elasticsearch.hosts` should not be used.
+This setting is an alternative to `monitoring.elasticsearch.hosts`.
+If `cloud_id` is configured, `monitoring.elasticsearch.hosts` should not be used.
 The {es} instances that you want to ship your Logstash metrics to. This might be
 the same {es} instance specified in the `outputs` section in your Logstash
 configuration, or a different one.
 
-`xpack.monitoring.elasticsearch.cloud_auth`::
+`monitoring.elasticsearch.cloud_auth`::
 
 If you're using {es} in {ecloud}, you can set your auth credentials here.
-This setting is an alternative to both `xpack.monitoring.elasticsearch.username`
-and `xpack.monitoring.elasticsearch.password`. If `cloud_auth` is configured,
+This setting is an alternative to both `monitoring.elasticsearch.username`
+and `monitoring.elasticsearch.password`. If `cloud_auth` is configured,
 those settings should not be used.