Fix docs builder errors (#220)

* Fix errors

* Fix more errors

* Fix more issues

* Fix relative

* Fix more links

* Fix remaining errors

* Remove acronym

Author: theletterf

.gitignore

@@ -14,4 +14,5 @@ __pycache__
 
 # .NET
 
-test/operator/dotnet/obj/**
+test/operator/dotnet/obj/**
+docs/.artifacts

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

@@ -14,7 +14,7 @@ products:
 
 On host or virtual machine environments, deploy local, per-host OpenTelemetry Collector instances, here referred to as OTel Collector in Agent Mode.
 
-![VM-Edge](./../images/arch-vm-edge.png)
+![VM-Edge](../images/arch-vm-edge.png)
 
 These collectors have two main purposes:
 
@@ -33,19 +33,20 @@ Elastic's Observability solution is technically compatible with edge setups that
 
 Elastic Cloud Serverless provides a managed OTLP endpoint for ingestion of OpenTelemetry data.
 
-![VM-Serverless](./../images/arch-vm-serverless.png)
+![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 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 in OTel-native format into the Elastic-hosted Elasticsearch.
 
-![VM-ECH](./../images/arch-vm-ech.png)
+![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).
 
 :::{note}
 The EDOT Gateway Collector does not send data through Elastic's Integration / APM Server on ECH to ingest data into Elasticsearch.
@@ -57,9 +58,9 @@ 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 into the self-managed Elastic Stack.
 
-![VM-self-managed](./../images/arch-vm-self-managed.png)
+![VM-self-managed](../images/arch-vm-self-managed.png)
 
 :::{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/architecture/k8s.md

@@ -14,7 +14,7 @@ products:
 
 The recommended OTel architecture for Kubernetes clusters includes a set of OpenTelemetry collectors in different modes. The following diagram shows the different modes:
 
-![K8s-Cluster](./../images/arch-k8s-cluster.png)
+![K8s-Cluster](../images/arch-k8s-cluster.png)
 
 ## Daemon mode
 
@@ -48,21 +48,22 @@ Elastic's Observability solution is technically compatible with setups that are
 
 Elastic Cloud Serverless provides a managed OTLP endpoint for ingestion of OpenTelemetry data.
 
-![K8s-Serverless](./../images/arch-k8s-serverless.png)
+![K8s-Serverless](../images/arch-k8s-serverless.png)
 
 For a Kubernetes setup, that means the Gateway Collector passes through the OTel data in native format using the OTLP protocol to the managed OTLP endpoint. There is no need for the Gateway Collector to do any Elastic-specific pre-processing.
 
 ### Elastic Cloud Hosted
 
 With Elastic Cloud Hosted (ECH), OTel data is being directly ingested into the Elastic-hosted Elasticsearch instance.
 
-![K8s-ECH](./../images/arch-k8s-ech.png)
+![K8s-ECH](../images/arch-k8s-ech.png)
 
 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).
 
 ::::{note}
 The EDOT Gateway Collector does not send data through Elastic's Integration / APM Server on ECH to ingest data into Elasticsearch.
@@ -76,11 +77,11 @@ If self-managing an EDOT Gateway is not a valid option for you, refer to [Elasti
 
 With a self-managed scenario the Gateway Collector ingests data directly into the self-managed Elasticsearch instance.
 
-![K8s-self-managed](./../images/arch-k8s-self-managed.png)
+![K8s-self-managed](../images/arch-k8s-self-managed.png)
 
 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/configure-logs-collection.md

@@ -64,7 +64,7 @@ receivers:
 
 The previous configuration can parse the following logs that span across multiple lines and recombine them properly into one single log message:
 
-```log
+```
 Exception in thread 1 "main" java.lang.NullPointerException
         at com.example.myproject.Book.getTitle(Book.java:16)
         at com.example.myproject.Author.getBookTitles(Author.java:25)

docs/reference/edot-collector/config/configure-metrics-collection.md

@@ -8,7 +8,7 @@ applies_to:
 products:
   - cloud-serverless
   - observability
-  - otel-collector
+  - edot-collector
 ---
 
 # Configure metrics collection