Fix errors

Author: theletterf

docs/docset.yml

@@ -18,6 +18,7 @@ cross_links:
   - docs-content
   - elasticsearch
   - kibana
+  - integrations
 toc:
   - toc: reference
 # - toc: release-notes

docs/reference/architecture/hosts_vms.md

@@ -35,17 +35,17 @@ Elastic Cloud Serverless provides a managed OTLP endpoint for ingestion of OpenT
 
 ![VM-Serverless](./../images/arch-vm-serverless.png)
 
-Users can send their OTel data from the [edge setup](#hosts--vms-environments) in OTel-native format through OTLP without any additional requirements for self-managed preprocessing of data.
+Users can send their OTel data from the [edge setup](#hosts-and-vms-environments) in OTel-native format through OTLP without any additional requirements for self-managed preprocessing of data.
 
 ### Elastic Cloud Hosted
 
-As of Elastic Stack version <STACK_VERSION> on Elastic Cloud Hosted (ECH), you need to run a self-hosted EDOT Collector in Gateway Mode to ingest OTel data from the [edge setup](#hosts--vms-environments) in OTel-native format into the Elastic-hosted Elasticsearch.
+As of Elastic Stack version 9.0 on Elastic Cloud Hosted (ECH), you need to run a self-hosted EDOT Collector in Gateway Mode to ingest OTel data from the [edge setup](#hosts-and-vms-environments) in OTel-native format into the Elastic-hosted Elasticsearch.
 
 ![VM-ECH](./../images/arch-vm-ech.png)
 
 The EDOT Collector in Gateway mode enriches and pre-aggregates the data for a seamless experience in the Elastic Observability solution before ingesting it directly into Elasticsearch.
 
-If required, users can build their custom, EDOT-like collector [following these instructions](../edot-collector/custom-collector#build-a-custom-edot-like-collector).
+If required, users can build their custom, EDOT-like collector [following these instructions](../edot-collector/custom-collector.md#build-a-custom-edot-like-collector).
 
 :::{note}
 The EDOT Gateway Collector does not send data through Elastic's Integration / APM Server on ECH to ingest data into Elasticsearch.
@@ -57,7 +57,7 @@ If self-managing an EDOT Gateway is not a valid option for you, refer to [Elasti
 
 ### Self-managed
 
-In a self-managed deployment scenario, you need to host an EDOT Collector in Gateway mode that pre-processes and ingests OTel data from the [edge setup](#hosts--vms-environments) into the self-managed Elastic Stack.
+In a self-managed deployment scenario, you need to host an EDOT Collector in Gateway mode that pre-processes and ingests OTel data from the [edge setup](#hosts-and-vms-environments) into the self-managed Elastic Stack.
 
 ![VM-self-managed](./../images/arch-vm-self-managed.png)
 

docs/reference/architecture/k8s.md

@@ -60,9 +60,10 @@ With Elastic Cloud Hosted (ECH), OTel data is being directly ingested into the E
 
 The Gateway Collector needs to do some preprocessing, aggregation of metrics and, finally, it uses the Elasticsearch exporter to ingest data into ECH. 
 
-While the Daemon and Cluster collectors, as well as the OTel SDKs, can stay fully vendor agnostic or upstream, the Gateway Collector needs to be either an EDOT Collector or a [custom, EDOT-like collector](../edot-collector/custom-collector) containing the [required components and pre-processing pipelines](../edot-collector/config/default-config-k8s#direct-ingestion-into-elasticsearch).
+While the Daemon and Cluster collectors, as well as the OTel SDKs, can stay fully vendor agnostic or upstream, the Gateway Collector needs to be either an EDOT Collector or a [custom, EDOT-like collector](../edot-collector/custom-collector.md) containing the
+[required components and pre-processing pipelines](../edot-collector/config/default-config-k8s.md#direct-ingestion-into-elasticsearch).
 
-If required, users can build their custom, EDOT-like collector [following these instructions](../edot-collector/custom-collector#build-a-custom-edot-like-collector).
+If required, users can build their custom, EDOT-like collector [following these instructions](../edot-collector/custom-collector.md#build-a-custom-edot-like-collector).
 
 ::::{note}
 The EDOT Gateway Collector does not send data through Elastic's Integration / APM Server on ECH to ingest data into Elasticsearch.
@@ -80,7 +81,7 @@ With a self-managed scenario the Gateway Collector ingests data directly into th
 
 The Gateway Collector does some preprocessing and aggregation of OTel data before ingesting it into Elasticsearch. 
 
-While the Daemon and Cluster collectors, as well as the OTel SDKs, can stay fully vendor agnostic or upstream, the Gateway Collector needs to be either an EDOT Collector or a [custom, EDOT-like collector](../edot-collector/custom-collector) containing the [required components and pre-processing pipelines](../edot-collector/config/default-config-k8s#direct-ingestion-into-elasticsearch).
+While the Daemon and Cluster collectors, as well as the OTel SDKs, can stay fully vendor agnostic or upstream, the Gateway Collector needs to be either an EDOT Collector or a [custom, EDOT-like collector](../edot-collector/custom-collector.md) containing the [required components and pre-processing pipelines](../edot-collector/config/default-config-k8s.md#direct-ingestion-into-elasticsearch).
 
 ::::{note}
 Compared to [Elastic's classic ingestion paths](https://www.elastic.co/guide/en/observability/current/apm-open-telemetry.html) for OTel data, with the EDOT Gateway Collector there is no need for an APM Server anymore.

docs/reference/compatibility/features.md

@@ -39,11 +39,11 @@ The following table shows Elastic features and their level of support and compat
 | Central management of OTel SDKs                                                             | [Incompatible]   |
 
 
-^1^ Refer to [limitations on host metrics](limitations.md#infrastructure--host-metrics)
+^1^ Refer to [limitations on host metrics](limitations.md#infrastructure-and-host-metrics)
 
 ^2^ Refer to [limitations on Ingest Pipelines](limitations.md#centralized-parsing-and-processing-of-data)
 
-^3^ Refer to [limitations on metrics ingestion](limitations.md#ingestion-of-metrics-data)
+^3^ Refer to [limitations on metrics ingestion](limitations.md#metrics-data-ingestion)
 
 [Incompatible]: nomenclature.md
 [Compatible]: nomenclature.md

docs/reference/compatibility/limitations.md

@@ -5,9 +5,9 @@ applies_to:
   stack:
   serverless:
     observability:
-  products:
-    - cloud-serverless
-    - observability
+products:
+   - cloud-serverless
+   - observability
 ---
 
 # Limitations of Elastic Distributions of OpenTelemetry

docs/reference/compatibility/nomenclature.md

@@ -23,7 +23,7 @@ In the following sections we differentiate the following compatibility and suppo
 | **State**        | **Description**                                                                                                                                                                                                                                                                                                               |
 | :--------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Incompatible** | Component, use case, or ingestion path is technically not compatible. Functionality is likely to be significantly impacted.                                                                                                                                                                                          |
-| **Compatible**   | Component, use case, or ingestion path is technically compatible. Functionality is not expected to be impaired. Minor deviations might occur. Component, use case, or ingestion path is *not officially supported by Elastic*. Elastic does not provide guaranteed support or troubleshooting assistance. |
+| **Compatible**   | Component, use case, or ingestion path is technically compatible. Functionality is not expected to be impaired. Minor deviations might occur. Component, use case, or ingestion path is not officially supported by Elastic. Elastic does not provide guaranteed support or troubleshooting assistance. |
 | **Supported**    | Component, use case, or ingestion path is technically compatible and Elastic provides official support. The functionality is explicitly tested. Limitations are documented.                                                                                                                                    |
 
 ## Categorization of Collector components

docs/reference/compatibility/sdks.md

@@ -24,7 +24,7 @@ The following table provides an overview of compatibility and support of EDOT SD
 | **EDOT Android**   | [Incompatible]   | [Compatible]      | [Supported]     |
 | **EDOT iOS**       | [Incompatible]   | [Compatible]      | [Supported]     |
 
-Refer to the [EDOT Collector compatibility table](collectors.md#edot-collector-compatibility-with-elastic-stack) for compatibility with Elastic Stack versions.
+Refer to the [EDOT Collector compatibility table](collectors.md) for compatibility with Elastic Stack versions.
 
 For the best experience, export data from EDOT SDKs using the [EDOT Collector](../edot-collector/index.md).
 

docs/reference/edot-collector/config/default-config-k8s.md

@@ -56,7 +56,7 @@ The Gateway collectors pipelines differ between the two different deployment use
 
 In self-managed and Elastic Cloud Hosted Stack deployment use cases, the main purpose of the Gateway collector is the central enrichment of data before the OpenTelemetry data is being ingested directly into Elasticsearch using the [`elasticsearch`] exporter.
 
-The Gateway collector configuration comprises the pipelines for data enrichment of [application telemetry](./default-config-standalone#application--traces-collection-pipeline) and [host metrics](./default-config-standalone#host-metrics-collection-pipeline). For more details, refer to the linked descriptions of the corresponding standalone use cases.
+The Gateway collector configuration comprises the pipelines for data enrichment of [application telemetry](./default-config-standalone.md#application--traces-collection-pipeline) and [host metrics](./default-config-standalone.md#host-metrics-collection-pipeline). For more details, refer to the linked descriptions of the corresponding standalone use cases.
 
 The [`routing`] connector separates the infrastructure metrics from other metrics and routes them into the ECS-based pipeline, with ECS-compatibility exporter mode. Other metrics are exported in OTel-native format to Elasticsearch.
 

docs/reference/edot-collector/customization.md

@@ -17,7 +17,7 @@ The EDOT Collector comes with a [curated list](./components.md) of OTel Collecto
 
 If your use case requires additional components, you have two options:
 
-1. [Build your custom, EDOT-like Collector](./custom-collector)
+1. [Build your custom, EDOT-like Collector](./custom-collector.md)
 2. [Open a request](https://github.com/elastic/elastic-agent/issues/new/choose) to add those components to EDOT.
 
 Requests for adding new components to the EDOT Collector will be reviewed and decided on the basis of the popularity of the requests, technical suitability and other criteria.

docs/reference/edot-collector/download.md

@@ -35,4 +35,4 @@ After you've downloaded and uncompressed the file, you can get EDOT Collector ru
 sudo ./otelcol --config otel.yml
 ```
 
-For specific configuration, refer to the [Quickstart guides](../quickstart) or refer to [Configuration](./config/index.md).
+For specific configuration, refer to the [Quickstart guides](../quickstart/index.md) or refer to [Configuration](./config/index.md).