Fix more issues

Author: theletterf

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,15 +33,15 @@ 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 in OTel-native format through OTLP without any additional requirements for self-managed preprocessing of data.
 
 ### Elastic Cloud Hosted
 
 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.
 
@@ -60,7 +60,7 @@ If self-managing an EDOT Gateway is not a valid option for you, refer to [Elasti
 
 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,15 +48,15 @@ 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. 
 
@@ -77,7 +77,7 @@ 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. 
 

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

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

@@ -13,7 +13,7 @@ products:
 
 # Default configuration of the EDOT Collector (Kubernetes)
 
-The [Kubernetes setup](../../quickstart/index.md) uses the OpenTelemetry Operator to automate orchestration of EDOT Collectors:
+The [Kubernetes setup](.../quickstart/index.md) uses the OpenTelemetry Operator to automate orchestration of EDOT Collectors:
 
 * [EDOT Collector Cluster](#cluster-collector-pipeline): Collection of cluster metrics.
 * [EDOT Collector Daemon](#daemonset-collectors-pipeline): Collection of node metrics, logs and application telemetry.

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

@@ -59,7 +59,7 @@ Both components, `elastictrace` and `elasticapm` are required for Elastic APM UI
 
 * Use the EDOT Collector with the available configuration to ingest data into Elasticsearch.
 * [Build a custom, EDOT-like Collector](../custom-collector.md) for ingesting data into Elasticsearch.
-* Use Elastic's [managed OTLP endpoint](../../quickstart/serverless/index.md) that does the enrichment for you.
+* Use Elastic's [managed OTLP endpoint](.../quickstart/serverless/index.md) that does the enrichment for you.
 :::
 
 ### Host metrics collection pipeline

docs/reference/edot-sdks/dotnet/migration.md

@@ -32,7 +32,7 @@ directly export data to an Elastic Observability backend (both in Elastic Cloud
 Elastic tooling may not be able to function as intended. For that reason, we provide Elastic distributions that
 provide a thin layer over the OpenTelemetry tools to provide our customers with the best compatibility, supportability and features. 
 We recommend using the Elastic Distribution of OpenTelemetry (EDOT) language SDK and the 
-[Elastic Distribution of OpenTelemetry collector](../../edot-collector/index.md) for the best experience.
+[Elastic Distribution of OpenTelemetry collector](.../edot-collector/index.md) for the best experience.
 
 This page guides migrating to EDOT .NET from either the existing 
 [Elastic APM Agent for .NET](https://www.elastic.co/guide/en/apm/agent/dotnet/current/index.html) or from the upstream

docs/reference/edot-sdks/dotnet/setup/console.md

@@ -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) documentation for more details.
 
 As an example, manual code-based configuration can be used to disable the instrumentation assembly scanning
 feature.

docs/reference/edot-sdks/dotnet/setup/edot-defaults.md

@@ -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).
 
 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/#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) and prefer manually registering
 all instrumentation in your application code.
 
 :::{warning}

docs/reference/edot-sdks/dotnet/setup/worker-services.md

@@ -37,7 +37,7 @@ The preceding code:
 1. Builds and runs the `IHost` to execute the application workload.
 
 Because the worker service template is based on the generic host, shared with ASP.NET Core applications, 
-this is the same approach as shown in the [getting started](index.md) and [ASP.NET Core](aspnetcore) examples
+this is the same approach as shown in the [getting started](index.md) and ASP.NET Core examples
 and the same techniques for configuration and usage apply.
 
 ## Instrumenting worker services

docs/reference/edot-sdks/dotnet/supported-technologies.md

@@ -16,13 +16,13 @@ from the [upstream SDK](https://github.com/open-telemetry/opentelemetry-dotnet).
 
 ## EDOT Collector / Elastic Stack versions
 
-EDOT .NET sends data via the OpenTelemetry protocol (OTLP). While OTLP ingest works with later 8.16+ versions of the EDOT Collector, for full support it is strongly recommended that you use either [EDOT Collector](../../edot-collector/index.md) versions 9.x or [Elastic Cloud Serverless](https://www.elastic.co/guide/en/serverless/current/intro.html) for OTLP ingest.
+EDOT .NET sends data via the OpenTelemetry protocol (OTLP). While OTLP ingest works with later 8.16+ versions of the EDOT Collector, for full support it is strongly recommended that you use either [EDOT Collector](.../edot-collector/index.md) versions 9.x or [Elastic Cloud Serverless](https://www.elastic.co/guide/en/serverless/current/intro.html) for OTLP ingest.
 
 :::{note}
 Ingesting data from EDOT SDKs through EDOT Collector 9.x into Elastic Stack versions 8.18+ *is supported*.
 :::
 
-See [EDOT SDKs compatibility](../../compatibility/sdks.md) for support details.
+See [EDOT SDKs compatibility](.../compatibility/sdks.md) for support details.
 
 ## .NET Frameworks