elastic · theletterf · May 9, 2025 · May 8, 2025 · May 8, 2025 · May 8, 2025
diff --git a/.gitignore b/.gitignore
@@ -14,4 +14,5 @@ __pycache__
 
 # .NET
 
-test/operator/dotnet/obj/**
+test/operator/dotnet/obj/**
+docs/.artifacts
@@ -1,4 +1,4 @@
 project: 'EDOT docs'
 cross_links:
  - apm-agent-android
  - apm-agent-dotnet
@@ -18,6 +18,7 @@
   - docs-content
   - elasticsearch
   - kibana
+  - integrations
 toc:
   - toc: reference
 # - toc: release-notes

@@ -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.

@@ -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.

@@ -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

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

@@ -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

@@ -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).
 

@@ -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)

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

@@ -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-and-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.
 

@@ -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.

@@ -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).
@@ -41,7 +41,7 @@ OpenTelemetry SDK.
 - [Migrating to EDOT .NET from Elastic .NET Agent](#migrating-to-edot-net-from-elastic-net-agent)
 - [Migrating to EDOT .NET from the upstream OpenTelemetry .NET SDK](#migrating-to-edot-net-from-the-upstream-opentelemetry-net-sdk)
 
-## Migrating to EDOT .NET from Elastic .NET Agent
+## Migrating to EDOT .NET from Elastic .NET Agent [migrating-to-edot-net-from-elastic-net-agent]
 
 ### Migrating manual application instrumentation
 
@@ -190,7 +190,7 @@ builder.AddElasticOpenTelemetry(b => b
 
 Here, we prefer the `AddElasticOpenTelemetry` extension method for the `IHostApplicationBuilder`.
 By default, EDOT .NET is configured to observe the most common instrumentation and export data via OTLP.
-See [opinionated defaults](./setup/edot-defaults) for more information.
+See [opinionated defaults](./setup/edot-defaults.md) for more information.
 
 The preceding code snippet adds one additional source to be observed, which matches the name
 we gave to the `ActivitySource` defined earlier.
@@ -259,12 +259,12 @@ process, service, or IIS application pool.
 To switch to the EDOT .NET zero-code auto instrumentation, the `COR_*` and `CORECLR_*` environment variables must
 be updated to point to the Elastic redistribution of the OpenTelemetry autoinstrumentation profiler.
 
-Please follow the steps in [Using EDOT .NET zero-code instrumentation](./setup/zero-code) to configure the profiler.
+Please follow the steps in [Using EDOT .NET zero-code instrumentation](./setup/zero-code.md) to configure the profiler.
 
-## Migrating to EDOT .NET from the upstream OpenTelemetry .NET SDK
+## Migrating to EDOT .NET from the upstream OpenTelemetry .NET SDK [migrating-to-edot-net-from-the-upstream-opentelemetry-net-sdk]
 
 Our design goal for EDOT .NET has been to introduce no new concepts and require minimal code changes to migrate
-from the upstream OpenTelemetry SDK for .NET to EDOT .NET as easily as possible. Our [opinionated defaults](./setup/edot-defaults)
+from the upstream OpenTelemetry SDK for .NET to EDOT .NET as easily as possible. Our [opinionated defaults](./setup/edot-defaults.md)
 strive to simplify the amount of code required to get started with OpenTelemetry in .NET applications.
 
 In an application which already uses the upstream OpenTelemetry SDK, the following code is an example of how

@@ -33,7 +33,7 @@ The preceding code:
 1. Imports the required types from the `OpenTelemetry` namespace.
 1. Creates an instance of the `OpenTelemetrySdk` using its factory `Create` method.
 1. Configures the `IOpenTelemetryBuilder` by passing a lambda.
-1. Enables EDOT .NET and its [opinionated defaults](edot-defaults) by calling `WithElasticDefaults` on the `IOpenTelemetryBuilder`.
+1. Enables EDOT .NET and its [opinionated defaults](edot-defaults.md) by calling `WithElasticDefaults` on the `IOpenTelemetryBuilder`.
 
 :::{warning}
 The `using` keyword is applied to the `sdk` variable to define a using declaration, which ensures that the
@@ -93,7 +93,7 @@ by your Elastic Observability backend.
 Several configuration settings are available to control the additional features offered by EDOT .NET.
 These may be configured using environment variables, `IConfiguration` and/or code-based configuration.
 
-See the [configuration](./../configuration) documentation for more details.
+See the [configuration](../configuration.md) documentation for more details.
 
 As an example, manual code-based configuration can be used to disable the instrumentation assembly scanning
 feature.

@@ -33,7 +33,7 @@ EDOT .NET enables:
 
 When sending data to an Elastic Observability backend, OTLP via the EDOT Collector is recommended for
 compatibility and is required for full support. EDOT .NET enables OTLP over gRPC as the default for all signals.
-This behaviour can be disabled using [configuration](./../configuration).
+This behaviour can be disabled using [configuration](../configuration.md).
 
 All signals are configured to apply EDOT .NET defaults for resource attributes via the `ResourceBuilder`.
 
@@ -269,7 +269,7 @@ OpenTelemetry SDK.
 | IncludeFormattedMessage  | `true`            | `false`                   |
 | IncludeScopes            | `false` (Since 1.0.2) *           | `false`                   |
 
-\* Since 1.0.2 `IncludeScopes` is no longer enabled by default. See [troubleshooting](./../troubleshooting/#missing-log-records).
+\* Since 1.0.2 `IncludeScopes` is no longer enabled by default. See [troubleshooting](../troubleshooting.md#missing-log-records).
 1.0.0 and 1.0.1 default to `true`.
 
 ### Instrumentation assembly scanning
@@ -286,7 +286,7 @@ code you need to manage.
 :::
 
 Alternatively, if you need to configure advanced options when registering instrumentation,
-disable instrumentation assembly scanning via [configuration](./../configuration) and prefer manually registering
+disable instrumentation assembly scanning via [configuration](../configuration.md) and prefer manually registering
 all instrumentation in your application code.
 
 :::{warning}