[DOCS] Removed UI and Logstash settings & updated links to that info.

Original commit: elastic/x-pack-elasticsearch@2434e503dd

docs/en/security/authentication.asciidoc

@@ -89,9 +89,9 @@ elasticsearch.password: kibanapassword
 -----------------------------------------------
 
 The `logstash_system` user is used internally within Logstash when
-<<monitoring-logstash-settings, monitoring>> is enabled for logstash
+monitoring is enabled for Logstash.
 
-If you wish to enable this feature in Logstash, then you need to update the Logstash
+To enable this feature in Logstash, you need to update the Logstash
 configuration with the new password by setting `xpack.monitoring.elasticsearch.password` in
 the `logstash.yml` configuration file:
 

docs/en/security/authentication/active-directory-realm.asciidoc

@@ -413,4 +413,4 @@ NOTE: By default, when you configure {security} to connect to Active Directory
       configuration do not match, {security} does not allow a connection to the
       Active Directory server. This is done to protect against man-in-the-middle
       attacks. If necessary, you can disable this behavior by setting the
-      <<ssl-tls-settings, `ssl.verification_mode`>> property to `none`.
+      {ref}/security-settings.html#ssl-tls-settings[`ssl.verification_mode`] property to `none`.

docs/en/security/authentication/pki-realm.asciidoc

@@ -104,7 +104,7 @@ xpack:
                                         the username from the certificate DN. The first match
                                         group is used as the username. Defaults to `CN=(.*?)(?:,\|$)`.
 | `truststore.path`       | no        | The path to the truststore. Defaults to the path
-                                        defined by <<ssl-tls-settings,SSL/TLS settings>>.
+                                        defined by  {ref}/security-settings.html#ssl-tls-settings[SSL/TLS settings].
 | `truststore.password`   | no/yes    | Specifies the password for the truststore. Must be
                                         provided if `truststore.path` is set.
 | `truststore.algorithm`  | no        | Specifies the algorithm used for the truststore.

docs/en/security/reference.asciidoc

@@ -1,12 +1,10 @@
 [[security-reference]]
 == Reference
 * <<security-privileges, Security Privileges>>
-* <<security-settings, Security Settings>>
+* {ref}/security-settings.html[Security Settings]
 * <<security-files, Security Files>>
 * <<security-api, Security API>>
 
 include::reference/privileges.asciidoc[]
 
-// include::reference/settings.asciidoc[]
-
 include::reference/files.asciidoc[]

docs/en/security/release-notes.asciidoc

@@ -258,7 +258,7 @@ June 24, 2015
 * The {ref-17}/query-dsl-terms-filter.html#_caching_19[terms filter lookup cache] has been disabled to ensure all requests
   are properly authorized. This removes the need to manually disable the terms filter cache.
 * For LDAP client connections, only the protocols and ciphers specified in the `shield.ssl.supported_protocols` and
-  `shield.ssl.ciphers` <<ssl-tls-settings,settings>> will be used.
+  `shield.ssl.ciphers`  {ref}/security-settings.html#ssl-tls-settings[settings] will be used.
 * The auditing mechanism now logs authentication failed events when a request contains an invalid authentication token.
 
 [float]

docs/en/security/securing-communications/enabling-cipher-suites.asciidoc

@@ -16,7 +16,7 @@ encryption with key lengths greater than 128 bits, such as 256-bit AES encryptio
 
 After installation, all cipher suites in the JCE are available for use. To enable
 the use of stronger cipher suites with {security}, configure the `cipher_suites`
-parameter. See the <<ssl-tls-settings, Configuration Parameters for TLS/SSL>>
+parameter. See the {ref}/security-settings.html#ssl-tls-settings[Configuration Parameters for TLS/SSL]
 section of this document for specific parameter information.
 
 NOTE: The _JCE Unlimited Strength Jurisdiction Policy Files_ must be installed

docs/en/security/tribe-clients-integrations/cross-cluster.asciidoc

@@ -29,7 +29,7 @@ To use cross cluster search with secured clusters:
   ** Using the same certificate authority to generate certificates for all
     connected clusters, or
   ** Adding the CA certificate from the local cluster as a trusted CA in
-    each remote cluster (see <<transport-tls-ssl-settings>>).
+    each remote cluster (see {ref}/security-settings.html#transport-tls-ssl-settings[Transport TLS settings]).
 
 * Configure the local cluster to connect to remote clusters as described
   in {ref}/modules-cross-cluster-search.html#_configuring_cross_cluster_search[Configuring Cross Cluster Search].

docs/en/security/tribe-clients-integrations/logstash.asciidoc

@@ -5,7 +5,7 @@ The Logstash Elasticsearch plugins (
 {logstash-ref}/plugins-outputs-elasticsearch.html[output],
 {logstash-ref}/plugins-inputs-elasticsearch.html[input],
 {logstash-ref}/plugins-filters-elasticsearch.html[filter]
-and <<monitoring-logstash-settings, monitoring>>)
+and {logstash-ref}/monitoring-logstash.html[monitoring]
 support authentication and encryption over HTTP.
 
 To use Logstash with a secured cluster, you need to configure authentication 
@@ -179,7 +179,7 @@ output {
 [[ls-monitoring-user]]
 ===== Configuring Logstash Monitoring
 
-If you wish to ship Logstash <<monitoring-logstash-settings, monitoring>>
+If you wish to ship Logstash {logstash-ref}/logstash-monitoring.html[monitoring]
 data to a secure cluster, Logstash must be configured with a username and password.
 
 X-Pack security comes preconfigured with a `logstash_system` user for this purpose.

docs/en/settings/configuring-xes.asciidoc

@@ -2,22 +2,9 @@
 [[settings-xpack]]
 == Configuring X-Pack
 
-You can configure {es} settings for {xpack} features in the `elasticsearch.yml`
+include::x-pack-settings.asciidoc
-file.
-
-If you are using {kib}, there are also settings in the `kibana.yml` file. See
-{kibana}/settings.html[Configuring {kib}].
-
-//TODO: Add link to "Configuring XPack" in Kibana Reference.
-
-The following settings pertain to specific {xpack} features:
-
-* <<ml-settings,Machine Learning Settings>>
-* {xpack-ref}/monitoring-settings.html[Monitoring Settings]
-* {xpack-ref}/security-settings.html[Security Settings]
-* {xpack-ref}/notification-settings.html[Watcher Settings]
-
-For more information, see <<settings>> and
-{xpack-ref}/xpack-settings.html[{xpack} Settings].
-
 include::ml-settings.asciidoc[]
+include::monitoring-settings.asciidoc[]
+include::security-settings.asciidoc[]
+include::notification-settings.asciidoc[]
+

docs/en/settings/index.asciidoc

@@ -1,12 +0,0 @@
-[[xpack-settings]]
-= X-Pack Settings
-
-[partintro]
---
-include::x-pack-settings.asciidoc
---
-
-include::ml-settings.asciidoc[]
-include::monitoring-settings.asciidoc[]
-include::security-settings.asciidoc[]
-include::notification-settings.asciidoc[]

docs/en/settings/monitoring-settings.asciidoc

@@ -1,20 +1,25 @@
 [[monitoring-settings]]
 == Monitoring Settings
 
-You configure <<monitoring-collection-settings, `xpack.monitoring.collection`>>
+Monitoring is enabled by default when you install {xpack}. You configure
+<<monitoring-collection-settings, `xpack.monitoring.collection`>>
 settings in `elasticsearch.yml` to control how data is collected from your
-Elasticsearch nodes. You can adjust how monitoring data is displayed in the
+Elasticsearch nodes.
-Monitoring UI by configuring <<monitoring-ui-settings, `xpack.monitoring`>>
-settings in `kibana.yml`.
 
-For more information, see <<configuring-monitoring, Configuring Monitoring>>.
+To adjust how monitoring data is displayed in the Monitoring UI, you configure
+{kibana-ref}/monitoring-settings-kb.html[`xpack.monitoring` settings] in
+`kibana.yml`. To control how monitoring data is collected from
+Logstash, you configure {logstash-ref}/settings-xpack.html#monitoring-settings[
+`xpack.monitoring` settings]  in `logstash.yml`.
+
+For more information, see
+{xpack-ref}/xpack-monitoring.html[Monitoring the Elastic Stack].
 
 [float]
 [[general-monitoring-settings]]
 === General Monitoring Settings
 `xpack.monitoring.enabled`::
-Set to `false` to disable {monitoring}.
+Set to `false` to disable {es} {monitoring} for Elasticsearch.
-Configure in both `elasticsearch.yml` and `kibana.yml`.
 
 [float]
 [[monitoring-collection-settings]]
@@ -82,213 +87,6 @@ IMPORTANT: This setting currently only impacts `local`-type exporters. Indices c
 the `http` exporter will not be deleted automatically.
 
 
-[float]
-[[monitoring-ui-settings]]
-=== Monitoring UI Settings
-
-You can set the following `xpack.monitoring` settings in `kibana.yml` to adjust
-how the Monitoring UI displays monitoring data. However, the defaults work best
-in most circumstances. For more information about configuring Kibana, see
-{kibana-ref}/settings.html[Setting Kibana
-Server Properties] in the Kibana User Guide.
-
-`xpack.monitoring.elasticsearch.url`::
-
-The location of the Elasticsearch instance(s) where your monitoring data is
-stored. By default, this is the same as the `elasticsearch.url`. This setting
-enables you to use a single Kibana instance to search and visualize data in
-your production cluster as well as monitor data sent to a dedicated monitoring
-cluster.
-
-`xpack.monitoring.kibana.collection.enabled`::
-
-Whether or not to enable data collection from the Kibana NodeJS server for
-Kibana Dashboards to be featured in the Monitoring UI. Defaults to `true`.
-
-`xpack.monitoring.kibana.collection.interval`::
-
-Number of milliseconds to wait in between data sampling for Kibana's NodeJS
-server for the metrics that are displayed in the Kibana dashboards. Defaults to
-`10000` (10 seconds).
-
-`xpack.monitoring.max_bucket_size`::
-
-The number of term buckets to return out of the overall terms list when
-performing terms aggregations to retrieve index and node metrics. For more
-information about the `size` parameter, see {ref}/search-aggregations-bucket-terms-aggregation.html#_size[
-Terms Aggregation] in the Elasticsearch Reference. Defaults to 10000.
-
-`xpack.monitoring.min_interval_seconds`::
-
-The minimum number of seconds that a time bucket in a chart can represent.
-Defaults to 10. If you modify the `xpack.monitoring.collection.interval`
-in `elasticsearch.yml`, set this option to the same value.
-
-`xpack.monitoring.node_resolver`::
-
-The node resolver controls how nodes are considered unique. This can be set to either `uuid`,
-`transport_address`, or `name`. `uuid` controls uniqueness based on the node's persistent ID.
-`transport_address` controls uniqueness based on the node's published
-hostname/IP and port. `name` controls uniqueness based on the node's `node.name` setting. Defaults to
-`uuid`.
-
-`xpack.monitoring.report_stats`::
-
-Whether or not to send cluster statistics to Elastic. Reporting your cluster statistics
-helps us improve your user experience. Your data is never shared with anyone. Set to
-`false` to disable statistics reporting from any browser connected to the Kibana instance.
-You can also opt-out on a per-browser basis through the Monitoring user interface. Defaults to `true`.
-
-`xpack.monitoring.ui.enabled`::
-
-Set to `false` to hide the Monitoring UI in Kibana. The Monitoring back-end
-continues to run as an agent for sending Kibana stats to the Monitoring
-cluster. Defaults to `true`.
-
-[float]
-[[monitoring-ui-cgroup-settings]]
-==== Monitoring UI Container Settings
-
-The Monitoring UI exposes the Cgroup statistics that we collect for you to make better decisions
-about your container performance, rather than guessing based on the overall machine performance.
-If you are not running your applications in a container, then Cgroup statistics will not be useful.
-
-`xpack.monitoring.ui.container.elasticsearch.enabled`::
-
-For Elasticsearch clusters that are running in containers, this setting changes the Node Listing to
-display the CPU Utilization based on the reported Cgroup statistics. This will also add the calculated
-Cgroup CPU Utilization to the Node Overview page instead of the overall operating system's CPU
-Utilization. Defaults to `false`.
-+
-image::images/monitoring-es-cgroup-true.png["Elasticsearch Inside a Container",link="images/monitoring-es-cgroup-true.png"]
-
-[float]
-[[local-exporter-settings]]
-==== Local Exporter Settings
-
-The `local` exporter is the default exporter used by Monitoring. As the name is
-meant to imply, it exports data to the _local_ cluster, which means that there
-is not much needed to be configured.
-
-If you do not supply _any_ exporters, then Monitoring will automatically create
-one for you. If any exporter is provided, then no default is added.
-
-[source,yaml]
-----------------------------------
-xpack.monitoring.exporters.my_local:
-  type: local
-----------------------------------
-
-`type`::
-
-The value for a Local exporter must always be `local` and it is required.
-
-`use_ingest`::
-
-Whether to supply a placeholder pipeline to the cluster and a pipeline processor with
-every bulk request. The default value is `true`. If disabled, then it means that it will not
-use pipelines, which means that a future release cannot automatically upgrade bulk requests
-to future-proof them.
-
-[float]
-[[http-exporter-settings]]
-==== HTTP Exporter Settings
-
-The following lists settings that can be supplied with the `http` exporter.
-All settings are shown as what follows the name you select for your exporter:
-
-[source,yaml]
-----------------------------------
-xpack.monitoring.exporters.my_remote:
-  type: http
-  host: ["host:port", ...]
-----------------------------------
-
-`type`::
-
-The value for an HTTP exporter must always be `http` and it is required.
-
-`host`::
-
-Host supports multiple formats, both as an array or as a single value. Supported formats include
-`hostname`, `hostname:port`, `http://hostname` `http://hostname:port`, `https://hostname`, and
-`https://hostname:port`. Hosts cannot be assumed. The default scheme is always `http` and the default
-port is always `9200` if not supplied as part of the `host` string.
-+
-[source,yaml]
-----------------------------------
-xpack.monitoring.exporters:
-  example1:
-    type: http
-    host: "10.1.2.3"
-  example2:
-    type: http
-    host: ["http://10.1.2.4"]
-  example3:
-    type: http
-    host: ["10.1.2.5", "10.1.2.6"]
-  example4:
-    type: http
-    host: ["https://10.1.2.3:9200"]
-----------------------------------
-
-`auth.username`::
-
-The username is required if a `auth.password` is supplied.
-
-`auth.password`::
-
-The password for the `auth.username`.
-
-`connection.timeout`::
-
-The amount of time that the HTTP connection is supposed to wait for a socket to open for the
-request. The default value is `6s`.
-
-`connection.read_timeout`::
-
-The amount of time that the HTTP connection is supposed to wait for a socket to
-send back a response. The default value is `10 * connection.timeout` (`60s` if neither are set).
-
-`ssl`::
-
-Each HTTP exporter can define its own TLS / SSL settings or inherit them. See the
-<<ssl-monitoring-settings, TLS / SSL section below>>.
-
-`proxy.base_path`::
-
-The base path to prefix any outgoing request, such as `/base/path` (e.g., bulk requests would
-then be sent as `/base/path/_bulk`). There is no default value.
-
-`headers`::
-
-Optional headers that are added to every request, which can assist with routing requests through
-proxies.
-+
-[source,yaml]
-----------------------------------
-xpack.monitoring.exporters.my_remote:
-  headers:
-    X-My-Array: [abc, def, xyz]
-    X-My-Header: abc123
-----------------------------------
-+
-Array-based headers are sent `n` times where `n` is the size of the array. `Content-Type`
-and `Content-Length` cannot be set. Any headers created by the Monitoring agent will override
-anything defined here.
-
-`index.name.time_format`::
-
-A mechanism for changing the default date suffix for the, by default, daily Monitoring indices.
-The default value is `YYYY.MM.DD`, which is why the indices are created daily.
-
-`use_ingest`::
-
-Whether to supply a placeholder pipeline to the monitoring cluster and a pipeline processor with
-every bulk request. The default value is `true`. If disabled, then it means that it will not
-use pipelines, which means that a future release cannot automatically upgrade bulk requests
-to future-proof them.
-
 [[ssl-monitoring-settings]]
 :ssl-prefix:             xpack.monitoring.exporters.$NAME
 :component:              {monitoring}
@@ -296,55 +94,3 @@ to future-proof them.
 :server!:
 
 include::ssl-settings.asciidoc[]
-
-[float]
-[[monitoring-logstash-settings]]
-=== Monitoring Logstash Settings
-
-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-ref}/logstash-settings-file.html[Settings File]
-section.
-
-`xpack.monitoring.enabled`::
-
-Set to `false` to disable X-Pack monitoring.
-
-`xpack.monitoring.collection.interval`::
-
-Controls how often data samples are collected and shipped on the Logstash side. Defaults to `10s`.
-
-`xpack.monitoring.elasticsearch.url`::
-
-The Elasticsearch instance(s) that you want to ship your Logstash metrics to.
-This might be the same Elasticsearch 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`.
-
-`xpack.monitoring.elasticsearch.username` and `xpack.monitoring.elasticsearch.password`::
-
-If your Elasticsearch is protected with basic authentication, these settings provide the username and
-password that the Logstash instance uses to authenticate for shipping monitoring data.
-
-`xpack.monitoring.elasticsearch.ssl.ca`::
-
-Optional setting that enables you to specify a path to the `.pem` file for the certificate authority for your Elasticsearch 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.

docs/en/settings/security-settings.asciidoc

@@ -6,7 +6,7 @@ You configure `xpack.security` settings  to
 and perform message authentication,
 <<field-document-security-settings, set up document and field 
 level security>>, <<realm-settings, configure realms>>, 
-and <<ssl-tls-settings, encrypt communications with SSL>>.
+and  {ref}/security-settings.html#ssl-tls-settings[encrypt communications with SSL].
 
 [float]
 [[general-security-settings]]

docs/en/settings/ssl-settings.asciidoc

@@ -1,7 +1,8 @@
 [float]
 === {component} TLS/SSL Settings
 You can configure the following TLS/SSL settings. If the settings are not configured,
-the <<ssl-tls-settings, {xpack} defaults>> will be used.
+the {xpack-ref}/security-settings.html#ssl-tls-settings[Default TLS/SSL Settings]
+are used.
 
 ifdef::server[]
 +{ssl-prefix}.ssl.enabled+::

docs/en/watcher/actions/email.asciidoc

@@ -426,7 +426,7 @@ You can control which HTML features are allowed or disallowed by configuring the
 `xpack.notification.email.html.sanitization.allow` and
 `xpack.notification.email.html.sanitization.disallow` settings in
 `elasticsearch.yml`. You can specify individual HTML elements and
-<<html-feature-groups, HTML feature groups>>. By default, {watcher} allows the following
+{ref}/notification-settings.html#html-feature-groups[HTML feature groups]. By default, {watcher} allows the following
 features: `body`, `head`, `_tables`, `_links`, `_blocks`, `_formatting` and
 `img:embedded`.
 

docs/en/watcher/actions/hipchat.asciidoc

@@ -232,8 +232,8 @@ xpack.notification.hipchat:
       room: monitoring
 --------------------------------------------------
 
-You can also specify defaults for the <<hipchat-account-attributes,
+You can also specify defaults for the {ref}/notification-settings.html#hipchat-account-attributes[
-message attributes>>:
+message attributes]:
 
 [source,yaml]
 --------------------------------------------------
@@ -295,8 +295,8 @@ xpack.notification.hipchat:
       auth_token: 3eLB803Nyp7UBmegJwP1rMdUmzk5HqnzJCgflrhv
 --------------------------------------------------
 
-You can also specify defaults for the <<hipchat-account-attributes,
+You can also specify defaults for the <{ref}/notification-settings.html#hipchat-account-attributes[
-message attributes>>:
+message attributes]:
 
 [source,yaml]
 --------------------------------------------------
@@ -360,8 +360,8 @@ xpack.notification.hipchat:
       auth_token: 3eLB803Nyp7UBmegJwP1rMdUmzk5HqnzJCgflrhv
 --------------------------------------------------
 
-You can also specify defaults for the <<hipchat-account-attributes,
+You can also specify defaults for the {ref}/notification-settings.html#hipchat-account-attributes[
-message attributes>>.
+message attributes].
 
 [source,yaml]
 --------------------------------------------------

docs/en/watcher/actions/jira.asciidoc

@@ -137,7 +137,8 @@ xpack.notification.jira:
 WARNING: It is strongly advised to use Basic Authentication with secured HTTPS
  protocol only.
 
-You can also specify defaults for the <<jira-account-attributes, Jira issues>>:
+You can also specify defaults for the
+{ref}/notification-settings.html#jira-account-attributes[Jira issues]:
 
 [source,yaml]
 --------------------------------------------------

docs/en/watcher/actions/slack.asciidoc

@@ -203,8 +203,8 @@ xpack.notification.slack:
       url: https://hooks.slack.com/services/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
 --------------------------------------------------
 
-You can also specify defaults for the <<slack-account-attributes, Slack
+You can also specify defaults for the {ref}/notification-settings.html#slack-account-attributes[Slack
-notification attributes>>:
+notification attributes]:
 
 [source,yaml]
 --------------------------------------------------

docs/en/watcher/actions/webhook.asciidoc

@@ -76,8 +76,8 @@ NOTE: By default, both the username and the password are stored in the `.watches
 You can also use PKI-based authentication when submitting requests to a cluster
 secured with {security}. When you use PKI-based authentication instead of HTTP
 basic auth, you don't need to store any authentication information in the watch
-itself. To use PKI-based authentication, you <<ssl-notification-settings,
+itself. To use PKI-based authentication, you {ref}/notification-settings.html#ssl-notification-settings
-configure the SSL key settings>> for {watcher} in `elasticsearch.yml`.
+[configure the SSL key settings] for {watcher} in `elasticsearch.yml`.
 
 
 [[webhook-query-parameters]]

docs/en/watcher/example-watches/example-watch-clusterstatus.asciidoc

@@ -100,8 +100,7 @@ PUT _xpack/watcher/watch/cluster_health_watch
 
 It would be a good idea to create a user with the minimum privileges required for use with such a watch configuration.
 
-Depending on how your cluster is configured, there may be additional settings required before the watch can access your cluster such as keystores, truststores or certificates.
+Depending on how your cluster is configured, there may be additional settings required before the watch can access your cluster such as keystores, truststores or certificates. For more information, see {ref}/notification-settings.html[Notification Settings].
-See the <<notification-settings,[Notification Settings>> section of the X-Pack Settings documentation.
 
 
 If you check the watch history, you'll see that the cluster status is recorded