[docs] Fix various syntax and rendering errors

deploy-manage/autoscaling/autoscaling-in-eck.md

@@ -222,7 +222,7 @@ kubectl get elasticsearchautoscaler autoscaling-sample \
     -o jsonpath='{ .status.conditions }' | jq
 ```
 
-```json
+```json subs=true
 [
  {
    "lastTransitionTime": "2022-09-09T08:07:10Z",

deploy-manage/cloud-organization/billing/billing-models.md

@@ -71,13 +71,13 @@ Based on these four key concepts, the prepaid consumption lifecycle is as follow
 1. You purchase credits expressed in ECU, typically at a discount.
 2. You begin using {{ecloud}} resources.
 3. At every billing cycle (which takes place on the first of each month), the previous month's usage, expressed in ECU, is deducted from your ECU balance.
-4. If your ECU balance is depleted before the credit expiration date, you are invoiced for on-demand usage in arrears at list price. On-demand usage is expressed in ECU, and is converted to currency amounts for invoicing purposes.¹
+4. If your ECU balance is depleted before the credit expiration date, you are invoiced for on-demand usage in arrears at list price. On-demand usage is expressed in ECU, and is converted to currency amounts for invoicing purposes.[^1^](#footnote-1)
 5. At the end of the contract period, any credits remaining in your balance are forfeited.
-6. During the contract period, you can purchase additional credits at any time (as an add-on). This can be done with the same discount as the original purchase. Credits purchased through an add-on have the same expiration as the original purchase.²
+6. During the contract period, you can purchase additional credits at any time (as an add-on). This can be done with the same discount as the original purchase. Credits purchased through an add-on have the same expiration as the original purchase.[^2^](#footnote-2)
 
-¹ When you renew your contract or commit to a multi-year contract, any on-demand usage incurred in the years other than the last are billed with the same discount as the original purchase.
+^1^ $$$footnote-1$$$ When you renew your contract or commit to a multi-year contract, any on-demand usage incurred in the years other than the last are billed with the same discount as the original purchase.
 
-² Purchasing credits through early renewals, or through add-ons with different expiration dates will be available in the near future.
+^2^ $$$footnote-2$$$ Purchasing credits through early renewals, or through add-ons with different expiration dates will be available in the near future.
 
 ::::{note}
 Existing annual+overages customers will be able to switch to prepaid consumption when they renew or sign a new contract. Existing manual burndown customers will be migrated gradually to prepaid consumption in the near future. Exceptions apply.

deploy-manage/deploy/cloud-enterprise/ce-add-support-for-node-roles-autoscaling.md

@@ -30,7 +30,7 @@ There are a number of fields that need to be added to each {{es}} node in order
 
 The following example is based on the `default` system owned deployment template that already supports `node_roles`. This template will be used as a reference for the next sections:
 
-::::{dropdown} Reference example with support for `node_roles`
+::::{dropdown} Reference example with support for node_roles
 :name: ece-node-roles-support-example
 
 ```json
@@ -363,7 +363,7 @@ It is recommended to add the `id` field to each {{es}} topology element in the d
 
 The existing template contains three {{es}} topology elements and two resources (`elasticsearch` and `kibana`).
 
-::::{dropdown} Custom example without support for `node_roles`
+::::{dropdown} Custom example without support for node_roles
 ```json
 {
   ...
@@ -471,7 +471,7 @@ Then, it is only necessary to add the four {{es}} topology elements (`warm`, `co
 
 After adding support for `node_roles`, the resulting deployment template should look similar to the following:
 
-::::{dropdown} Custom example with support for `node_roles`
+::::{dropdown} Custom example with support for node_roles
 :name: example-with-support-for-node-roles
 
 ```json
@@ -772,7 +772,7 @@ These fields represent the default settings for the deployment. However, autosca
 
 Similar to the `node_roles` example, the following one is also based on the `default` deployment template that already supports `node_roles` and autoscaling. This template will be used as a reference for the next sections:
 
-::::{dropdown} Reference example with support for `node_roles` and autoscaling
+::::{dropdown} Reference example with support for node_roles and autoscaling
 ```json
 {
   ...
@@ -1102,7 +1102,7 @@ To update a custom deployment template:
 
 After adding support for autoscaling to the [example](#ece-node-roles-support-example) presented in the previous section, the resulting deployment template should look similar to the following:
 
-::::{dropdown} Custom example with support for `node_roles` and autoscaling
+::::{dropdown} Custom example with support for node_roles and autoscaling
 ```json
 {
   ...
@@ -1780,7 +1780,7 @@ After the migration plan has finished, we recommend following the [Migrate index
 
 The following is an example of a deployment plan that does not contain `node_roles`:
 
-::::{dropdown} Example deployment plan with `node_type`
+::::{dropdown} Example deployment plan with node_type
 ```json
 {
   "name": "Example deployment",
@@ -1924,7 +1924,7 @@ The following is an example of a deployment plan that does not contain `node_rol
 
 After adding support for `node_roles` to the example deployment plan, the resulting plan should look similar to the following:
 
-::::{dropdown} Example deployment plan with `node_roles`
+::::{dropdown} Example deployment plan with node_roles
 ```json
 {
   "name": "Example deployment",

deploy-manage/deploy/cloud-enterprise/ece-install-offline-no-registry.md

@@ -27,7 +27,7 @@ To perform an offline installation without a private Docker registry, you have t
     For example, for {{ece}} 4.0.0 and the {{stack}} versions it shipped with, you need:
 
     * {{ece}} 4.0.0
-    * {es} 9.0.0, {{kib}} 9.0.0, and APM 9.0.0
+    * {{es}} 9.0.0, {{kib}} 9.0.0, and APM 9.0.0
 
 2. Create .tar files of the images:
 

deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md

@@ -10,7 +10,7 @@ mapped_pages:
 
 Custom endpoint aliases allow users to replace the UUID for each application with a human readable string. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments.
 
-::::{note} 
+::::{note}
 You need to update your proxy certificates to support this feature.
 ::::
 
@@ -20,16 +20,16 @@ After installing or upgrading to version 2.10 or later:
 1. [Login to the Cloud UI](log-into-cloud-ui.md)
 2. [Update your proxy certificate(s)](../../security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). In addition to currently configured domains, additional SAN entries must be configured for each application-specific subdomain:
 
-    ::::{note} 
+    ::::{note}
     If you are not using wildcard certificates, you need to repeat this process for each deployment to account for specific aliases.
     ::::
 
 
-    * For {{es}}, the certificate needs to allow for ***.es.<your-domain>**
-    * For {{kib}}, the certificate needs to allow for ***.kb.<your-domain>**
-    * For APM, the certificate needs to allow for ***.apm.<your-domain>**
-    * For Fleet, the certificate needs to allow for ***.fleet.<your-domain>**
-    * For Universal Profiling, the certificate needs to allow for ***.profiling.<your-domain>** and ***.symbols.<your-domain>**
+    * For {{es}}, the certificate needs to allow for **\*.es.<your-domain>**
+    * For {{kib}}, the certificate needs to allow for **\*.kb.<your-domain>**
+    * For APM, the certificate needs to allow for **\*.apm.<your-domain>**
+    * For Fleet, the certificate needs to allow for **\*.fleet.<your-domain>**
+    * For Universal Profiling, the certificate needs to allow for **\*.profiling.<your-domain>** and **\*.symbols.<your-domain>**
 
 3. In the **Platform** menu, select **Settings**.
 4. Under the **Enable custom endpoint alias naming**, toggle the setting to allow platform administrators and deployment managers to choose a simplified, unique URL for the endpoint.

deploy-manage/deploy/cloud-enterprise/manage-elastic-stack-versions.md

@@ -45,7 +45,7 @@ $$$ece-elastic-stack-stackpacks-recent$$$
 
 Following is the full list of available packs containing {{stack}} versions. Note that Enterprise Search was introduced with ECE 2.6.0 and requires that version or higher.
 
-::::{dropdown} **Expand to view the full list**
+::::{dropdown} Expand to view the full list
 | Required downloads | Minimum required ECE version |
 | --- | --- |
 | [{{es}}, {{kib}}, and APM stack pack: 9.0.0](https://download.elastic.co/cloud-enterprise/versions/9.0.0.zip) | ECE 4.0.0 |

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

@@ -17,7 +17,11 @@ This section covers the following topics:
 
 ## Use APM Agent central configuration [k8s-apm-agent-central-configuration]
 
-[APM Agent configuration management](/solutions/observability/apm/apm-agent-central-configuration.md) [7.5.1] allows you to configure your APM Agents centrally from the {{kib}} APM app. To use this feature, the APM Server needs to be configured with connection details of the {{kib}} instance. If {{kib}} is managed by ECK, you can simply add a `kibanaRef` attribute to the APM Server specification:
+:::{admonition} Added in 7.5.1
+APM Agent central configuration was added in 7.5.1.
+:::
+
+[APM Agent configuration management](/solutions/observability/apm/apm-agent-central-configuration.md) allows you to configure your APM Agents centrally from the {{kib}} APM app. To use this feature, the APM Server needs to be configured with connection details of the {{kib}} instance. If {{kib}} is managed by ECK, you can simply add a `kibanaRef` attribute to the APM Server specification:
 
 ```yaml
 cat <<EOF | kubectl apply -f -

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

@@ -174,14 +174,14 @@ Logstash persistent queues (PQs) and dead letter queues (DLQs) are not currently
 
 ## Defining data volumes for Logstash [k8s-logstash-volumes]
 
-[2.9.0]
+:::{admonition} Added in 2.9.0
+This was added in 2.9.0.
+:::
 
 ::::{warning}
 Volume support for Logstash is a breaking change to earlier versions of ECK and requires you to recreate your Logstash resources.
 ::::
 
-
-
 ## Specifying the volume claim settings [k8s-volume-claim-settings]
 
 A PersistentVolume called `logstash-data` is created by default. It maps to `/usr/share/logstash/data` for persistent storage, which is typically used for storage from plugins.

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

@@ -303,13 +303,13 @@ $$$azure-integration-whats-included$$$What is included in my {{ecloud}} deployme
 $$$azure-integration-how-to-access$$$How can I access my {{ecloud}} deployment?
 :   Navigate to the deployment overview page in Azure:
 
-    1. Select a deployment to open the deployment overview page.
+    Select a deployment to open the deployment overview page.
 
-        You now have a few options to access your deployment:
+    Then you have a few options to access your deployment:
 
-        * **{{es}} endpoint** - the URL for the {{es}} cluster itself
-        * **{{kib}} endpoint** - the UI for the {{stack}}, a great way for new users to get started
-        * **{{ecloud}}** - Open the **Advanced Settings** link to access the deployment in the {{ecloud}} console, to change the size of the deployment or upgrade it.
+    * **{{es}} endpoint** - the URL for the {{es}} cluster itself
+    * **{{kib}} endpoint** - the UI for the {{stack}}, a great way for new users to get started
+    * **{{ecloud}}** - Open the **Advanced Settings** link to access the deployment in the {{ecloud}} console, to change the size of the deployment or upgrade it.
 
 
 $$$azure-integration-modify-deployment$$$How can I modify my {{ecloud}} deployment?

deploy-manage/deploy/elastic-cloud/project-settings.md

@@ -61,7 +61,7 @@ For {{elastic-sec}} projects, edit the **Project features** to select a feature
 | Feature tier | Description and add-ons |
 | :--- | :--- |
 | **Security Analytics Essentials** | Standard security analytics, detections, investigations, and collaborations. Allows these add-ons:<br><br>* **Endpoint Protection Essentials**: endpoint protections with {{elastic-defend}}.<br>* **Cloud Protection Essentials**: Cloud native security features.<br> |
-| **Security Analytics Complete** | Everything in **Security Analytics Essentials*** plus advanced features such as entity analytics, threat intelligence, and more. Allows these add-ons:<br><br>* **Endpoint Protection Complete**: Everything in **Endpoint Protection Essentials** plus advanced endpoint detection and response features.<br>* **Cloud Protection Complete**: Everything in **Cloud Protection Essentials** plus advanced cloud security features.<br> |
+| **Security Analytics Complete** | Everything in **Security Analytics Essentials** plus advanced features such as entity analytics, threat intelligence, and more. Allows these add-ons:<br><br>* **Endpoint Protection Complete**: Everything in **Endpoint Protection Essentials** plus advanced endpoint detection and response features.<br>* **Cloud Protection Complete**: Everything in **Cloud Protection Essentials** plus advanced cloud security features.<br> |
 
 ### Downgrading the feature tier [elasticsearch-manage-project-downgrading-the-feature-tier]
 

deploy-manage/distributed-architecture/discovery-cluster-formation/modules-discovery-voting.md

@@ -58,7 +58,7 @@ It is important that the bootstrap configuration identifies exactly which nodes
 If the bootstrap configuration is not set correctly, when you start a brand-new cluster there is a risk that you will accidentally form two separate clusters instead of one. This situation can lead to data loss: you might start using both clusters before you notice that anything has gone wrong and it is impossible to merge them together later.
 
 ::::{note}
-To illustrate the problem with configuring each node to expect a certain cluster size, imagine starting up a three-node cluster in which each node knows that it is going to be part of a three-node cluster. A majority of three nodes is two, so normally the first two nodes to discover each other form a cluster and the third node joins them a short time later. However, imagine that four nodes were erroneously started instead of three. In this case, there are enough nodes to form two separate clusters. Of course if each node is started manually then it’s unlikely that too many nodes are started. If you’re using an automated orchestrator, however, it’s certainly possible to get into this situation-- particularly if the orchestrator is not resilient to failures such as network partitions.
+To illustrate the problem with configuring each node to expect a certain cluster size, imagine starting up a three-node cluster in which each node knows that it is going to be part of a three-node cluster. A majority of three nodes is two, so normally the first two nodes to discover each other form a cluster and the third node joins them a short time later. However, imagine that four nodes were erroneously started instead of three. In this case, there are enough nodes to form two separate clusters. Of course if each node is started manually then it’s unlikely that too many nodes are started. If you’re using an automated orchestrator, however, it’s certainly possible to get into this situation—particularly if the orchestrator is not resilient to failures such as network partitions.
 ::::
 
 The initial quorum is only required the very first time a whole cluster starts up. New nodes joining an established cluster can safely obtain all the information they need from the elected master. Nodes that have previously been part of a cluster will have stored to disk all the information that is required when they restart.

deploy-manage/monitor/autoops/ec-autoops-faq.md

@@ -20,7 +20,7 @@ $$$faq-autoops-monitoring$$$Does AutoOps monitor the entire {{stack}}?
 :   AutoOps is currently limited to {{es}} (not {{kib}}, Logstash and Beats).
 
 $$$faq-autoops-supported-versions$$$What versions of {{es}} are supported for {{ech}}?
-:   AutoOps supports {es} versions according to the [supported {{stack}} versions](https://www.elastic.co/support/eol).
+:   AutoOps supports {{es}} versions according to the [supported {{stack}} versions](https://www.elastic.co/support/eol).
 
 $$$faq-autoops-license$$$How is AutoOps currently licensed?
 :   AutoOps current feature set is available to {{ech}} customers at all subscription tiers. For more information refer to the [subscription page](https://www.elastic.co/subscriptions/cloud).

deploy-manage/monitor/logging-configuration/kib-advanced-logging.md

@@ -3,7 +3,7 @@ mapped_pages:
   - https://www.elastic.co/guide/en/kibana/current/_cli_configuration.html
 applies_to:
   deployment:
-    self: 
+    self:
     ece:
     eck:
 ---
@@ -18,7 +18,7 @@ If you are planning to ingest your logs using {{es}} or another tool, we recomme
 You can't configure these settings in an {{ech}} deployment.
 :::
 
-The {{kib}} logging system has three main components: *loggers*, *appenders* and *layouts*. 
+The {{kib}} logging system has three main components: *loggers*, *appenders* and *layouts*.
 
 * **Loggers** define what logging settings should be applied to a particular logger.
 * [Appenders](#logging-appenders) define where log messages are displayed (for example, stdout or console) and stored (for example, file on the disk).
@@ -70,7 +70,7 @@ The following conversions are provided out of the box:
 
 * **message**: Outputs the application supplied message associated with the logging event.
 
-* **meta**: Outputs the entries of `meta` object data in ***json** format, if one is present in the event. Example of `%meta` output:
+* **meta**: Outputs the entries of `meta` object data in **json** format, if one is present in the event. Example of `%meta` output:
 
     ```bash
     // Meta{from: 'v7', to: 'v8'}
@@ -391,7 +391,7 @@ logging:
       level: debug
 ```
 
-## Logging configuration using the CLI [logging-cli-migration] 
+## Logging configuration using the CLI [logging-cli-migration]
 
 You can specify your logging configuration using the CLI. For convenience, the `--verbose` and `--silent` flags exist as shortcuts and will continue to be supported beyond v7.
 

deploy-manage/remote-clusters/ec-remote-cluster-self-managed.md

@@ -132,7 +132,7 @@ A deployment can be configured to trust all or specific deployments in any envir
         Trust management will not work properly in clusters without an `otherName` value specified, as is the case by default in an out-of-the-box [{{es}} installation](../deploy/self-managed/installing-elasticsearch.md). To have the {{es}} certutil generate new certificates with the `otherName` attribute, use the file input with the `cn` attribute as in the example below.
         ::::
 
-5. . Provide a name for the trusted environment. That name will appear in the trust summary of your deployment’s **Security** page.
+5. Provide a name for the trusted environment. That name will appear in the trust summary of your deployment’s **Security** page.
 6. Select **Create trust** to complete the configuration.
 7. Configure the self-managed cluster to trust this deployment, so that both deployments are configured to trust each other: