fix brackets for subs

deploy-manage/deploy/cloud-on-k8s/configuration-examples-fleet.md

@@ -12,16 +12,16 @@ The examples in this section are for illustration purposes only and should not b
 ::::
 
 
-## System and {{k8s}} {integrations} [k8s_system_and_k8s_integrations]
+## System and {{k8s}} {{integrations}} [k8s_system_and_k8s_integrations]
 
 ```sh
 kubectl apply -f https://raw.githubusercontent.com/elastic/cloud-on-k8s/2.16/config/recipes/elastic-agent/fleet-kubernetes-integration.yaml
 ```
 
-Deploys {{agent}} as a DaemonSet in {{fleet}} mode with System and {{k8s}} {integrations} enabled. System integration collects syslog logs, auth logs and system metrics (for CPU, I/O, filesystem, memory, network, process and others). {{k8s}} {integrations} collects API server, Container, Event, Node, Pod, Volume and system metrics.
+Deploys {{agent}} as a DaemonSet in {{fleet}} mode with System and {{k8s}} {{integrations}} enabled. System integration collects syslog logs, auth logs and system metrics (for CPU, I/O, filesystem, memory, network, process and others). {{k8s}} {{integrations}} collects API server, Container, Event, Node, Pod, Volume and system metrics.
 
 
-## System and {{k8s}} {integrations} running as non-root [k8s_system_and_k8s_integrations_running_as_non_root]
+## System and {{k8s}} {{integrations}} running as non-root [k8s_system_and_k8s_integrations_running_as_non_root]
 
 ```sh
 kubectl apply -f https://raw.githubusercontent.com/elastic/cloud-on-k8s/2.16/config/recipes/elastic-agent/fleet-kubernetes-integration-nonroot.yaml

deploy-manage/deploy/cloud-on-k8s/configuration-fleet.md

@@ -216,7 +216,7 @@ roleRef:
 
 ## Deploy {{agent}} in secured clusters [k8s-elastic-agent-fleet-configuration-deploying-in-secured-clusters]
 
-To deploy {{agent}} in clusters with the Pod Security Policy admission controller enabled, or in [OpenShift](k8s-openshift-agent.md) clusters, you might need to grant additional permissions to the Service Account used by the {{agent}} Pods. Those Service Accounts must be bound to a Role or ClusterRole that has `use` permission for the required Pod Security Policy or Security Context Constraints. Different {{agent}} {integrations} might require different settings set in their PSP/[SCC](k8s-openshift-agent.md).
+To deploy {{agent}} in clusters with the Pod Security Policy admission controller enabled, or in [OpenShift](k8s-openshift-agent.md) clusters, you might need to grant additional permissions to the Service Account used by the {{agent}} Pods. Those Service Accounts must be bound to a Role or ClusterRole that has `use` permission for the required Pod Security Policy or Security Context Constraints. Different {{agent}} {{integrations}} might require different settings set in their PSP/[SCC](k8s-openshift-agent.md).
 
 
 ## Customize {{fleet-server}} Service [k8s-elastic-agent-fleet-configuration-customize-fleet-server-service]

deploy-manage/deploy/cloud-on-k8s/k8s_prerequisites.md

@@ -172,7 +172,7 @@ spec:
       podSelector:
         matchLabels:
           common.k8s.elastic.co/type: elasticsearch
-          # [Optional] Restrict to a single {es} cluster named hulk.
+          # [Optional] Restrict to a single {{es}} cluster named hulk.
           # elasticsearch.k8s.elastic.co/cluster-name=hulk
   - ports:
     - port: 53

deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md

@@ -298,7 +298,7 @@ $$$azure-integration-whats-included$$$What is included in my {{ecloud}} deployme
 :   Each {{ecloud}} deployment includes:
 
     * An {{es}} cluster
-    * A {{kib}} instance which provides data visualization and a front-end for the {stack}
+    * A {{kib}} instance which provides data visualization and a front-end for the {{stack}}
     * An APM server that allows you to easily collect application traces
     * An {{ents}} instance that allows you to easily build a search experience with an intuitive interface
 

deploy-manage/deploy/self-managed/configure-elasticsearch.md

@@ -14,7 +14,7 @@ The configuration files should contain settings which are node-specific (such as
 
 {{es}} has three configuration files:
 
-* `elasticsearch.yml` for configuring {es}
+* `elasticsearch.yml` for configuring {{es}}
 * `jvm.options` for configuring {{es}} JVM settings
 * `log4j2.properties` for configuring {{es}} logging
 

deploy-manage/deploy/self-managed/install-elasticsearch-with-docker.md

@@ -202,11 +202,11 @@ To remove the containers and their network, run:
 # Remove the Elastic network
 docker network rm elastic
 
-# Remove {es} containers
+# Remove {{es}} containers
 docker rm es01
 docker rm es02
 
-# Remove the {kib} container
+# Remove the {{kib}} container
 docker rm kib01
 ```
 

deploy-manage/deploy/self-managed/install-elasticsearch-with-zip-on-windows.md

@@ -10,7 +10,7 @@ mapped_pages:
 This package contains both free and subscription features. [Start a 30-day trial](https://www.elastic.co/guide/en/elasticsearch/reference/current/license-settings.html) to try out all of the features.
 
 ::::{note}
-On Windows the {{es}} {ml} feature requires the Microsoft Universal C Runtime library. This is built into Windows 10, Windows Server 2016 and more recent versions of Windows. For older versions of Windows it can be installed via Windows Update, or from a [separate download](https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows). If you cannot install the Microsoft Universal C Runtime library you can still use the rest of {{es}} if you disable the {{ml}} feature.
+On Windows the {{es}} {{ml}} feature requires the Microsoft Universal C Runtime library. This is built into Windows 10, Windows Server 2016 and more recent versions of Windows. For older versions of Windows it can be installed via Windows Update, or from a [separate download](https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows). If you cannot install the Microsoft Universal C Runtime library you can still use the rest of {{es}} if you disable the {{ml}} feature.
 ::::
 
 

deploy-manage/deploy/self-managed/install-with-docker.md

@@ -151,10 +151,10 @@ To remove the containers and their network, run:
 # Remove the Elastic network
 docker network rm elastic
 
-# Remove the {es} container
+# Remove the {{es}} container
 docker rm es01
 
-# Remove the {kib} container
+# Remove the {{kib}} container
 docker rm kib01
 ```
 

deploy-manage/monitor/monitoring-data/kibana-alerts.md

@@ -12,17 +12,17 @@ applies:
 
 # Kibana alerts [kibana-alerts]
 
-The {{stack}} {monitor-features} provide [Alerting rules](../../../explore-analyze/alerts-cases/alerts.md) out-of-the box to notify you of potential issues in the {{stack}}. These rules are preconfigured based on the best practices recommended by Elastic. However, you can tailor them to meet your specific needs.
+The {{stack}} {{monitor-features}} provide [Alerting rules](../../../explore-analyze/alerts-cases/alerts.md) out-of-the box to notify you of potential issues in the {{stack}}. These rules are preconfigured based on the best practices recommended by Elastic. However, you can tailor them to meet your specific needs.
 
 :::{image} ../../../images/kibana-monitoring-kibana-alerting-notification.png
-:alt: {{kib}} alerting notifications in {stack-monitor-app}
+:alt: {{kib}} alerting notifications in {{stack-monitor-app}}
 :class: screenshot
 :::
 
 When you open **{{stack-monitor-app}}** for the first time, you will be asked to acknowledge the creation of these default rules. They are initially configured to detect and notify on various conditions across your monitored clusters. You can view notifications for: **Cluster health**, **Resource utilization**, and **Errors and exceptions** for {{es}} in real time.
 
 ::::{note}
-The default {{watcher}} based "cluster alerts" for {{stack-monitor-app}} have been recreated as rules in {{kib}} {alert-features}. For this reason, the existing {{watcher}} email action `monitoring.cluster_alerts.email_notifications.email_address` no longer works. The default action for all {{stack-monitor-app}} rules is to write to {{kib}} logs and display a notification in the UI.
+The default {{watcher}} based "cluster alerts" for {{stack-monitor-app}} have been recreated as rules in {{kib}} {{alert-features}}. For this reason, the existing {{watcher}} email action `monitoring.cluster_alerts.email_notifications.email_address` no longer works. The default action for all {{stack-monitor-app}} rules is to write to {{kib}} logs and display a notification in the UI.
 ::::
 
 

deploy-manage/monitor/monitoring-data/monitor-troubleshooting.md

@@ -12,7 +12,7 @@ applies:
 # Troubleshooting [monitor-troubleshooting]
 
 
-Use the information in this section to troubleshoot common problems and find answers for frequently asked questions related to the {{kib}} {monitor-features}.
+Use the information in this section to troubleshoot common problems and find answers for frequently asked questions related to the {{kib}} {{monitor-features}}.
 
 
 ## Cannot view the cluster because the license information is invalid [_cannot_view_the_cluster_because_the_license_information_is_invalid] 

deploy-manage/monitor/monitoring-data/visualizing-monitoring-data.md

@@ -10,7 +10,7 @@ applies:
 
 # Visualizing monitoring data [xpack-monitoring]
 
-The {{kib}} {monitor-features} serve two separate purposes:
+The {{kib}} {{monitor-features}} serve two separate purposes:
 
 1. To visualize monitoring data from across the {{stack}}. You can view health and performance data for {{es}}, {{ls}}, {{ents}}, APM, and Beats in real time, as well as analyze past performance.
 2. To monitor {{kib}} itself and route that data to the monitoring cluster.

deploy-manage/monitor/stack-monitoring/collecting-log-data-with-filebeat.md

@@ -26,7 +26,7 @@ If you’re using {{agent}}, do not deploy {{filebeat}} for log collection. Inst
 
 2. Identify which logs you want to monitor.
 
-    The {{filebeat}} {es} module can handle [audit logs](../logging-configuration/logfile-audit-output.md), [deprecation logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md#deprecation-logging), [gc logs](https://www.elastic.co/guide/en/elasticsearch/reference/current/advanced-configuration.html#gc-logging), [server logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md), and [slow logs](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-slowlog.html). For more information about the location of your {{es}} logs, see the [path.logs](../../deploy/self-managed/important-settings-configuration.md#path-settings) setting.
+    The {{filebeat}} {{es}} module can handle [audit logs](../logging-configuration/logfile-audit-output.md), [deprecation logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md#deprecation-logging), [gc logs](https://www.elastic.co/guide/en/elasticsearch/reference/current/advanced-configuration.html#gc-logging), [server logs](../logging-configuration/elasticsearch-log4j-configuration-self-managed.md), and [slow logs](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-slowlog.html). For more information about the location of your {{es}} logs, see the [path.logs](../../deploy/self-managed/important-settings-configuration.md#path-settings) setting.
 
     ::::{important} 
     If there are both structured (`*.json`) and unstructured (plain text) versions of the logs, you must use the structured logs. Otherwise, they might not appear in the appropriate context in {{kib}}.
@@ -54,11 +54,11 @@ If you’re using {{agent}}, do not deploy {{filebeat}} for log collection. Inst
     If you configured the monitoring cluster to use encrypted communications, you must access it via HTTPS. For example, use a `hosts` setting like `https://es-mon-1:9200`.
 
     ::::{important} 
-    The {{es}} {monitor-features} use ingest pipelines, therefore the cluster that stores the monitoring data must have at least one [ingest node](../../../manage-data/ingest/transform-enrich/ingest-pipelines.md).
+    The {{es}} {{monitor-features}} use ingest pipelines, therefore the cluster that stores the monitoring data must have at least one [ingest node](../../../manage-data/ingest/transform-enrich/ingest-pipelines.md).
     ::::
 
 
-    If {{es}} {security-features} are enabled on the monitoring cluster, you must provide a valid user ID and password so that {{filebeat}} can send metrics successfully.
+    If {{es}} {{security-features}} are enabled on the monitoring cluster, you must provide a valid user ID and password so that {{filebeat}} can send metrics successfully.
 
     For more information about these configuration options, see [Configure the {{es}} output](https://www.elastic.co/guide/en/beats/filebeat/current/elasticsearch-output.html).
 

deploy-manage/monitor/stack-monitoring/collecting-monitoring-data-with-metricbeat.md

@@ -93,11 +93,11 @@ Want to use {{agent}} instead? Refer to [Collecting monitoring data with {{agent
     If you configured the monitoring cluster to use encrypted communications, you must access it via HTTPS. For example, use a `hosts` setting like `https://es-mon-1:9200`.
 
     ::::{important}
-    The {{es}} {monitor-features} use ingest pipelines, therefore the cluster that stores the monitoring data must have at least one [ingest node](../../../manage-data/ingest/transform-enrich/ingest-pipelines.md).
+    The {{es}} {{monitor-features}} use ingest pipelines, therefore the cluster that stores the monitoring data must have at least one [ingest node](../../../manage-data/ingest/transform-enrich/ingest-pipelines.md).
     ::::
 
 
-    If {{es}} {security-features} are enabled on the monitoring cluster, you must provide a valid user ID and password so that {{metricbeat}} can send metrics successfully:
+    If {{es}} {{security-features}} are enabled on the monitoring cluster, you must provide a valid user ID and password so that {{metricbeat}} can send metrics successfully:
 
     1. Create a user on the monitoring cluster that has the [`remote_monitoring_agent` built-in role](../../users-roles/cluster-or-deployment-auth/built-in-roles.md). Alternatively, use the [`remote_monitoring_user` built-in user](../../users-roles/cluster-or-deployment-auth/built-in-users.md).
     2. Add the `username` and `password` settings to the {{es}} output information in the {{metricbeat}} configuration file.

deploy-manage/monitor/stack-monitoring/es-http-exporter.md

@@ -15,7 +15,7 @@ If you have previously configured legacy collection methods, you should migrate
 ::::
 
 
-The `http` exporter is the preferred exporter in the {{es}} {monitor-features} because it enables the use of a separate monitoring cluster. As a secondary benefit, it avoids using a production cluster node as a coordinating node for indexing monitoring data because all requests are HTTP requests to the monitoring cluster.
+The `http` exporter is the preferred exporter in the {{es}} {{monitor-features}} because it enables the use of a separate monitoring cluster. As a secondary benefit, it avoids using a production cluster node as a coordinating node for indexing monitoring data because all requests are HTTP requests to the monitoring cluster.
 
 The `http` exporter uses the low-level {{es}} REST Client, which enables it to send its data to any {{es}} cluster it can access through the network. Its requests make use of the [`filter_path`](https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#common-options-response-filtering) parameter to reduce bandwidth whenever possible, which helps to ensure that communications between the production and monitoring clusters are as lightweight as possible.
 
@@ -46,7 +46,7 @@ xpack.monitoring.exporters:
 1. A `local` exporter defined explicitly whose arbitrary name is `my_local`.
 2. An `http` exporter defined whose arbitrary name is `my_remote`. This name uniquely defines the exporter but is otherwise unused.
 3. `host` is a required setting for `http` exporters. It must specify the HTTP port rather than the transport port. The default port value is `9200`.
-4. User authentication for those using {{stack}} {security-features} or some other form of user authentication protecting the cluster.
+4. User authentication for those using {{stack}} {{security-features}} or some other form of user authentication protecting the cluster.
 5. See [HTTP exporter settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/monitoring-settings.html#http-exporter-settings) for all TLS/SSL settings. If not supplied, the default node-level TLS/SSL settings are used.
 6. Optional base path to prefix any outgoing request with in order to work with proxies.
 7. Arbitrary key/value pairs to define as headers to send with every request. The array-based key/value format sends one header per value.

deploy-manage/monitor/stack-monitoring/es-legacy-collection-methods.md

@@ -29,7 +29,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md).
     1. Verify that the `xpack.monitoring.elasticsearch.collection.enabled` setting is `true`, which is its default value, on each node in the cluster.
 
         ::::{note} 
-        You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{es}} {security-features} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them.
+        You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them.
         ::::
 
 
@@ -38,7 +38,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md).
     2. Set the `xpack.monitoring.collection.enabled` setting to `true` on each node in the cluster. By default, it is disabled (`false`).
 
         ::::{note} 
-        You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{es}} {security-features} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them.
+        You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them.
         ::::
 
 
@@ -78,7 +78,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md).
     By default, the data is stored on the same cluster by using a [`local` exporter](es-local-exporter.md). Alternatively, you can use an [`http` exporter](es-http-exporter.md) to send data to a separate *monitoring cluster*.
 
     ::::{important} 
-    The {{es}} {monitor-features} use ingest pipelines, therefore the cluster that stores the monitoring data must have at least one [ingest node](../../../manage-data/ingest/transform-enrich/ingest-pipelines.md).
+    The {{es}} {{monitor-features}} use ingest pipelines, therefore the cluster that stores the monitoring data must have at least one [ingest node](../../../manage-data/ingest/transform-enrich/ingest-pipelines.md).
     ::::
 
 

deploy-manage/monitor/stack-monitoring/es-local-exporter.md

@@ -36,7 +36,7 @@ For the `local` exporter, all setup occurs only on the elected master node. This
 
 The elected master node is the only node to set up resources for the `local` exporter. Therefore all other nodes wait for the resources to be set up before indexing any monitoring data from their own collectors. Each of these nodes logs a message indicating that they are waiting for the resources to be set up.
 
-One benefit of the `local` exporter is that it lives within the cluster and therefore no extra configuration is required when the cluster is secured with {{stack}} {security-features}. All operations, including indexing operations, that occur from a `local` exporter make use of the internal transport mechanisms within {{es}}. This behavior enables the exporter to be used without providing any user credentials when {{security-features}} are enabled.
+One benefit of the `local` exporter is that it lives within the cluster and therefore no extra configuration is required when the cluster is secured with {{stack}} {{security-features}}. All operations, including indexing operations, that occur from a `local` exporter make use of the internal transport mechanisms within {{es}}. This behavior enables the exporter to be used without providing any user credentials when {{security-features}} are enabled.
 
 For more information about the configuration options for the `local` exporter, see [Local exporter settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/monitoring-settings.html#local-exporter-settings).