Merge branch 'main' into llm-observability

Author: alaudazzi

deploy-manage/autoscaling/autoscaling-deciders.md

@@ -18,7 +18,7 @@ applies_to:
 
 [Autoscaling](/deploy-manage/autoscaling.md) in Elasticsearch enables dynamic resource allocation based on predefined policies. A key component of this mechanism is autoscaling deciders, which independently assess resource requirements and determine when scaling actions are necessary. Deciders analyze various factors, such as storage usage, indexing rates, and machine learning workloads, to ensure clusters maintain optimal performance without manual intervention.
 
-::::{admonition} Indirect use only 
+::::{admonition} Indirect use only
 This feature is designed for indirect use by {{ech}}, {{ece}}, and {{eck}}. Direct use is not supported.
 ::::
 
@@ -49,7 +49,7 @@ The [autoscaling](../../deploy-manage/autoscaling.md) reactive storage decider (
 
 The reactive storage decider is enabled for all policies governing data nodes and has no configuration options.
 
-The decider relies partially on using [data tier preference](../../manage-data/lifecycle/data-tiers.md#data-tier-allocation) allocation rather than node attributes. In particular, scaling a data tier into existence (starting the first node in a tier) will result in starting a node in any data tier that is empty if not using allocation based on data tier preference. Using the [ILM migrate](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/index-lifecycle-actions/ilm-migrate.md) action to migrate between tiers is the preferred way of allocating to tiers and fully supports scaling a tier into existence.
+The decider relies partially on using [data tier preference](../../manage-data/lifecycle/data-tiers.md#data-tier-allocation) allocation rather than node attributes. In particular, scaling a data tier into existence (starting the first node in a tier) will result in starting a node in any data tier that is empty if not using allocation based on data tier preference. Using the [ILM migrate](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-migrate.md) action to migrate between tiers is the preferred way of allocating to tiers and fully supports scaling a tier into existence.
 
 ## Proactive storage decider [autoscaling-proactive-storage-decider]
 
@@ -62,7 +62,7 @@ The estimation of expected additional data is based on past indexing that occurr
 ### Configuration settings [autoscaling-proactive-storage-decider-settings]
 
 `forecast_window`
-:   (Optional, [time value](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/rest-apis/api-conventions.md#time-units)) The window of time to use for forecasting. Defaults to 30 minutes.
+:   (Optional, [time value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#time-units)) The window of time to use for forecasting. Defaults to 30 minutes.
 
 
 ### {{api-examples-title}} [autoscaling-proactive-storage-decider-examples]
@@ -96,7 +96,7 @@ The [autoscaling](../../deploy-manage/autoscaling.md) frozen shards decider (`fr
 ### Configuration settings [autoscaling-frozen-shards-decider-settings]
 
 `memory_per_shard`
-:   (Optional, [byte value](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) The memory needed per shard, in bytes. Defaults to 2000 shards per 64 GB node (roughly 32 MB per shard). Notice that this is total memory, not heap, assuming that the Elasticsearch default heap sizing mechanism is used and that nodes are not bigger than 64 GB.
+:   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) The memory needed per shard, in bytes. Defaults to 2000 shards per 64 GB node (roughly 32 MB per shard). Notice that this is total memory, not heap, assuming that the Elasticsearch default heap sizing mechanism is used and that nodes are not bigger than 64 GB.
 
 ## Frozen storage decider [autoscaling-frozen-storage-decider]
 
@@ -121,8 +121,8 @@ The [autoscaling](../../deploy-manage/autoscaling.md) {{ml}} decider (`ml`) calc
 
 The {{ml}} decider is enabled for policies governing `ml` nodes.
 
-::::{note} 
-For {{ml}} jobs to open when the cluster is not appropriately scaled, set `xpack.ml.max_lazy_ml_nodes` to the largest number of possible {{ml}} nodes (refer to [Advanced machine learning settings](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/configuration-reference/machine-learning-settings.md#advanced-ml-settings) for more information). In {{ess}}, this is automatically set.
+::::{note}
+For {{ml}} jobs to open when the cluster is not appropriately scaled, set `xpack.ml.max_lazy_ml_nodes` to the largest number of possible {{ml}} nodes (refer to [Advanced machine learning settings](elasticsearch://reference/elasticsearch/configuration-reference/machine-learning-settings.md#advanced-ml-settings) for more information). In {{ess}}, this is automatically set.
 ::::
 
 
@@ -137,7 +137,7 @@ Both `num_anomaly_jobs_in_queue` and `num_analytics_jobs_in_queue` are designed
 :   (Optional, integer) Specifies the number of queued {{dfanalytics-jobs}} to allow. Defaults to `0`.
 
 `down_scale_delay`
-:   (Optional, [time value](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/rest-apis/api-conventions.md#time-units)) Specifies the time to delay before scaling down. Defaults to 1 hour. If a scale down is possible for the entire time window, then a scale down is requested. If the cluster requires a scale up during the window, the window is reset.
+:   (Optional, [time value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#time-units)) Specifies the time to delay before scaling down. Defaults to 1 hour. If a scale down is possible for the entire time window, then a scale down is requested. If the cluster requires a scale up during the window, the window is reset.
 
 
 ### {{api-examples-title}} [autoscaling-machine-learning-decider-examples]
@@ -168,12 +168,12 @@ The API returns the following result:
 
 ## Fixed decider [autoscaling-fixed-decider]
 
-::::{warning} 
+::::{warning}
 This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.
 ::::
 
 
-::::{warning} 
+::::{warning}
 The fixed decider is intended for testing only. Do not use this decider in production.
 ::::
 
@@ -183,10 +183,10 @@ The [autoscaling](../../deploy-manage/autoscaling.md) `fixed` decider responds w
 ### Configuration settings [_configuration_settings]
 
 `storage`
-:   (Optional, [byte value](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) Required amount of node-level storage. Defaults to `-1` (disabled).
+:   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) Required amount of node-level storage. Defaults to `-1` (disabled).
 
 `memory`
-:   (Optional, [byte value](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) Required amount of node-level memory. Defaults to `-1` (disabled).
+:   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) Required amount of node-level memory. Defaults to `-1` (disabled).
 
 `processors`
 :   (Optional, float) Required number of processors. Defaults to disabled.

deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md

@@ -60,7 +60,7 @@ Data transfer out of deployments and between nodes of the cluster is hard to con
 
 The largest contributor to inter-node data transfer is usually shard movement between nodes in a cluster.  The only way to prevent shard movement is by having a single node in a single availability zone. This solution is only possible for clusters up to 64GB RAM and is not recommended as it creates a risk of data loss. [Oversharding](/deploy-manage/production-guidance/optimize-performance/size-shards.md) can cause excessive shard movement. Avoiding oversharding can also help control costs and improve performance. Note that creating snapshots generates inter-node data transfer. The *storage* cost of snapshots is detailed later in this document.
 
-The exact root cause of unusual data transfer is not always something we can identify as it can have many causes, some of which are out of our control and not associated with Cloud configuration changes.  It may help to [enable monitoring](../../monitor/stack-monitoring/elastic-cloud-stack-monitoring.md) and examine index and shard activity on your cluster.
+The exact root cause of unusual data transfer is not always something we can identify as it can have many causes, some of which are out of our control and not associated with Cloud configuration changes.  It may help to [enable monitoring](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md) and examine index and shard activity on your cluster.
 
 
 ## Storage [storage] 

deploy-manage/deploy.md

@@ -23,10 +23,10 @@ Your choice of deployment type determines how you'll set up and manage these cor
 This section focuses on deploying and managing {{es}} and {{kib}}, as well as supporting orchestration technologies. However, depending on your use case, you might need to deploy [other {{stack}} components](/get-started/the-stack.md). For example, you might need to add components to ingest logs or metrics.
 
 To learn how to deploy optional {{stack}} components, refer to the following sections:
-* [Fleet and Elastic Agent](asciidocalypse://docs/docs-content/docs/reference/ingestion-tools/fleet/index.md)
+* [Fleet and Elastic Agent](/reference/ingestion-tools/fleet/index.md)
 * [APM](/solutions/observability/apps/application-performance-monitoring-apm.md)
-* [Beats](asciidocalypse://docs/beats/docs/reference/index.md)
-* [Logstash](asciidocalypse://docs/logstash/docs/reference/index.md)
+* [Beats](beats://reference/index.md)
+* [Logstash](logstash://reference/index.md)
 :::
 
 ## Choosing your deployment type
@@ -74,7 +74,7 @@ Orchestrators manage the lifecycle of your Elastic deployments but don't change
 - You can add other Elastic products as needed
 - The orchestrator handles operational tasks while you focus on using and configuring the products
 
-### Versioning and compatibility 
+### Versioning and compatibility
 
 In {{serverless-full}}, you automatically get access to the latest versions of Elastic features and you don't need to manage version compatibility.
 
@@ -86,7 +86,7 @@ Consider this when choosing your deployment type:
 - Choose other deployment types if you need more control over version management
 
 :::{tip}
-Learn more about [versioning and availability](/get-started/versioning-availability.md). 
+Learn more about [versioning and availability](/get-started/versioning-availability.md).
 :::
 
 ### Cost considerations

deploy-manage/deploy/_snippets/installation-order.md

@@ -3,7 +3,7 @@ If you're deploying the {{stack}} in a self-managed cluster, then install the {{
 * {{es}}
 * {{kib}}
 * [Logstash](logstash://reference/index.md)
-* [{{agent}}](/reference/ingestion-tools/fleet/index.md) or [Beats](asciidocalypse://docs/beats/docs/reference/index.md)
+* [{{agent}}](/reference/ingestion-tools/fleet/index.md) or [Beats](beats://reference/index.md)
 * [APM](/solutions/observability/apps/application-performance-monitoring-apm.md)
 * [Elasticsearch Hadoop](elasticsearch-hadoop://reference/index.md)
 

deploy-manage/deploy/cloud-enterprise/air-gapped-install.md

@@ -19,7 +19,7 @@ Before you start, you must:
 * Follow the same prerequisites described in [](./install.md#ece-install-prerequisites). This includes [](./identify-deployment-scenario.md) and [](./prepare-environment.md) steps.
 * [Configure your operating system](./configure-operating-system.md) in all ECE hosts.
 * Be part of the `docker` group to run the installation script. You should not install Elastic Cloud Enterprise as the `root` user.
-* Set up and run a local copy of the Elastic Package Repository, otherwise your deployments with APM server and Elastic agent won’t work. Refer to the [Running EPR in air-gapped environments](asciidocalypse://docs/docs-content/docs/reference/ingestion-tools/fleet/air-gapped.md#air-gapped-diy-epr) documentation.
+* Set up and run a local copy of the Elastic Package Repository, otherwise your deployments with APM server and Elastic agent won’t work. Refer to the [Running EPR in air-gapped environments](/reference/ingestion-tools/fleet/air-gapped.md#air-gapped-diy-epr) documentation.
 
 When you are ready to install ECE, you can proceed:
 

deploy-manage/deploy/cloud-enterprise/connect-elasticsearch.md

@@ -86,24 +86,24 @@ To use the Cloud ID, you need:
     * A user ID and password that has permission to send data to your {{es}} cluster.
 
 ::::{important}
-        In our examples, we use the `elastic` superuser that every {{es}} cluster comes with. The password for the `elastic` user is provided when you create a deployment (and can also be [reset](../../users-roles/cluster-or-deployment-auth/built-in-users.md) if you forget it). On a production system, you should adapt these examples by creating a user that can write to and access only the minimally required indices. For each Beat, review the specific feature and role table, similar to the one in [Metricbeat](asciidocalypse://docs/beats/docs/reference/metricbeat/feature-roles.md) documentation.
+        In our examples, we use the `elastic` superuser that every {{es}} cluster comes with. The password for the `elastic` user is provided when you create a deployment (and can also be [reset](../../users-roles/cluster-or-deployment-auth/built-in-users.md) if you forget it). On a production system, you should adapt these examples by creating a user that can write to and access only the minimally required indices. For each Beat, review the specific feature and role table, similar to the one in [Metricbeat](beats://reference/metricbeat/feature-roles.md) documentation.
 ::::
 
 ### Example: Configure Beats with your Cloud ID [ece-cloud-id-beats]
 
 The following example shows how you can send operational data from Metricbeat to a new ECE deployment by using the Cloud ID. While this example uses Metricbeat, the same approach applies to other Beats.
 
 ::::{tip}
-For others, you can learn more about [getting started](asciidocalypse://docs/beats/docs/reference/index.md) with each Beat.
+For others, you can learn more about [getting started](beats://reference/index.md) with each Beat.
 ::::
 
 To get started with Metricbeat and {{ece}}:
 
 1. [Log into the Cloud UI](log-into-cloud-ui.md).
 2. [Create a new deployment](create-deployment.md) and copy down the password for the `elastic` user.
 3. On the deployment overview page, copy down the Cloud ID.
-4. Set up the Beat of your choice, such as [Metricbeat](asciidocalypse://docs/beats/docs/reference/metricbeat/metricbeat-installation-configuration.md).
-5. [Configure the Beat output to send to Elastic Cloud](asciidocalypse://docs/beats/docs/reference/metricbeat/configure-cloud-id.md).
+4. Set up the Beat of your choice, such as [Metricbeat](beats://reference/metricbeat/metricbeat-installation-configuration.md).
+5. [Configure the Beat output to send to Elastic Cloud](beats://reference/metricbeat/configure-cloud-id.md).
 
     ::::{note}
     Make sure you replace the values for `cloud.id` and `cloud.auth` with your own information.

deploy-manage/deploy/cloud-enterprise/ece-configuring-ece-create-templates.md

@@ -76,7 +76,7 @@ Before you start creating your own deployment templates, you should have: [tagge
 9. On this page you can [configure index management](ece-configure-templates-index-management.md) by assigning attributes to each of the data nodes in the deployment template. In Kibana, you can configure an index lifecycle management (ILM) policy, based on the node attributes, to control how data moves across the nodes in your deployment.
 10. Select **Stack features**.
 11. You can select a [snapshot repository](../../tools/snapshot-and-restore/cloud-enterprise.md) to be used by default for deployment backups.
-12. You can choose to [enable logging and monitoring](../../monitor/stack-monitoring/ece-stack-monitoring.md) by default, so that deployment logs and metrics are send to a dedicated monitoring deployment, and so that additional log types, retention options, and Kibana visualizations are available on all deployments created using this template.
+12. You can choose to [enable logging and monitoring](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md) by default, so that deployment logs and metrics are send to a dedicated monitoring deployment, and so that additional log types, retention options, and Kibana visualizations are available on all deployments created using this template.
 13. Select **Extensions**.
 14. Select any Elasticsearch extensions that you would like to be available automatically to all deployments created using the template.
 15. Select **Save and create template**.

deploy-manage/deploy/cloud-enterprise/manage-integrations-server.md

@@ -8,7 +8,7 @@ mapped_urls:
 
 # Manage your Integrations Server [ece-manage-integrations-server]
 
-For deployments that are version 8.0 and later, you have the option to add a combined [Application Performance Monitoring (APM) Server](/solutions/observability/apps/application-performance-monitoring-apm.md) and [Fleet Server](asciidocalypse://docs/docs-content/docs/reference/ingestion-tools/fleet/index.md) to your deployment. APM allows you to monitor software services and applications in real time, turning that data into documents stored in the Elasticsearch cluster. Fleet allows you to centrally manage Elastic Agents on many hosts.
+For deployments that are version 8.0 and later, you have the option to add a combined [Application Performance Monitoring (APM) Server](/solutions/observability/apps/application-performance-monitoring-apm.md) and [Fleet Server](/reference/ingestion-tools/fleet/index.md) to your deployment. APM allows you to monitor software services and applications in real time, turning that data into documents stored in the Elasticsearch cluster. Fleet allows you to centrally manage Elastic Agents on many hosts.
 
 As part of provisioning, the APM Server and Fleet Server are already configured to work with Elasticsearch and Kibana. At the end of provisioning, you are shown the secret token to configure communication between the APM Server and the backend [APM Agents](https://www.elastic.co/guide/en/apm/agent/index.html). The APM Agents get deployed within your services and applications.
 

deploy-manage/deploy/cloud-enterprise/system-deployments-configuration.md

@@ -69,7 +69,7 @@ In the case of the `admin-console-elasticsearch` and `security` system deploymen
 The `logging-and-metrics` cluster is different since, as an ECE admin, you likely want to provide users with access to the cluster in order to troubleshoot issues without your assistance, for example. In order to manage access to that cluster, you can configure roles that will provide access to the relevant indices, map those to users, and manage access to Kibana by leveraging the Elastic security integration with your authentication provider, such as LDAP, SAML, or AD. To configure one of those security realms, check [LDAP](../../users-roles/cluster-or-deployment-auth/ldap.md), [Active Directory](../../users-roles/cluster-or-deployment-auth/active-directory.md) or [SAML](../../users-roles/cluster-or-deployment-auth/saml.md).
 
 ::::{note} 
-The `logging-and-metrics` cluster is only intended for troubleshooting ECE deployment issues. If your use case involves modifying or normalizing logs from {{es}} or {{kib}}, use a separate [dedicated monitoring deployment](../../monitor/stack-monitoring/ece-stack-monitoring.md) instead.
+The `logging-and-metrics` cluster is only intended for troubleshooting ECE deployment issues. If your use case involves modifying or normalizing logs from {{es}} or {{kib}}, use a separate [dedicated monitoring deployment](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md) instead.
 ::::
 
 You can’t use ECE’s single sign-on (SSO) to access system deployments.