Apply suggestions from code review

Co-authored-by: Miguel Luna <[email protected]>

Author: theletterf

docs/reference/architecture/hosts_vms.md

@@ -13,11 +13,11 @@ products:
 
 # Hosts and VMs environments
 
-On host or virtual machine environments, deploy local, per-host OpenTelemetry Collector instances at the [edge](index.md#understanding-edge-deployment), close to your data sources.
+On host or virtual machine environments, deploy local, per-host OpenTelemetry Collector instances at these [edge](index.md#understanding-edge-deployment) host or VMs where your applications are running.
 
 ![VM-Edge](../images/arch-vm-edge.png)
 
-These edge collectors have two main purposes:
+Collectors deployed on these edge environments have two main purposes:
 
 1.  The collection of local logs and infrastructure metrics. Refer to [this sample config file](https://github.com/elastic/elastic-agent/blob/main/internal/pkg/otel/samples/linux/managed_otlp/platformlogs_hostmetrics.yml) for recommended Collector receiver configurations for hostmetrics and logs.
 2.  Enriching application telemetry from OTel SDKs that run within the instrumented applications on corresponding hosts with resource information.
@@ -36,23 +36,25 @@ Elastic's Observability solution is technically compatible with edge setups that
 
 ![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.
+Users can send data direct from the Collectors or SDKs deployed on the edge environment via OTLP without any additional requirements for managing an ingestion layer.
 
 ### {{ech}}
 ```{applies_to}
 ess:
 stack: preview 9.2
 ```
 
-{{ech}} provides a [Managed OTLP Endpoint](/reference/motlp.md) for ingestion of OpenTelemetry 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.
+{{ech}} provides a [Managed OTLP Endpoint](/reference/motlp.md) for ingestion of OpenTelemetry data. Users can send data direct from the Collectors or SDKs deployed on the edge environment via OTLP without any additional requirements for managing an ingestion layer.
 
 Alternatively, you can run a self-hosted EDOT Collector in gateway mode to ingest OTel data from the edge setup. The EDOT Collector in gateway mode enriches and pre-aggregates the data before ingesting it directly into {{es}}. If required, you can build your custom, EDOT-like Collector [following these instructions](elastic-agent://reference/edot-collector/custom-collector.md).
 
 ![VM-ECH](../images/arch-vm-ech.png)
 
 ### Self-managed
 
-In a self-managed deployment scenario, you need to host an EDOT Collector in gateway mode that preprocesses and ingests OTel data from the edge setup into the self-managed {{stack}}.
+In a self-managed Elastic deployment, we recommend running an EDOT Collector in gateway mode as a unified ingestion layer for OTLP telemetry from OpenTelemetry collectors or SDKs running at the edge. This gateway can receive all signals (logs, metrics and traces), apply processing as needed, and cover the same use cases that previously required components like APM Server or Logstash.
+
+Depending on your scalability and durability needs, this can be a single collector that scales horizontally, or a chain of collectors where each tier handles a specific concern. For high availability and stronger durability guarantees, you can insert Kafka between tiers so that ingestion is buffered and resilient to downstream outages.
 
 ![VM-self-managed](../images/arch-vm-self-managed.png)
 

docs/reference/architecture/index.md

@@ -20,20 +20,22 @@ The following sections outline the recommended architectures for Elastic Distrib
 
 ## Understanding edge deployment
 
-In the context of OpenTelemetry architecture, 'edge' refers to collectors deployed close to your data sources: running on individual hosts, virtual machines, or as daemon sets on Kubernetes nodes. These edge collectors perform two primary functions:
+In the context of OpenTelemetry architecture, 'edge' refers to the environment where applications are running: individual hosts, virtual machines, or as daemon sets on Kubernetes nodes. Collectors deployed in these environments perform two primary functions:
 
 1. They gather logs, infrastructure metrics, application traces, profiles, and other telemetry from the local environment.
 2. They enrich application telemetry from OpenTelemetry SDKs running on the same host or node with resource metadata, such as host information and Kubernetes attributes.
 
-### Collector flexibility at the edge
+### Vendor neutral collector deployments on edge environments
 
 You can use any OpenTelemetry Collector distribution at the edge, including:
 
 - The contrib OpenTelemetry Collector.
 - Custom-built Collector distributions.
 - The {{edot}} Collector.
+- Any shipper capable of sending valid OTLP data.
 
-The only requirement is that edge collectors send data using the OpenTelemetry Protocol (OTLP) to either a gateway Collector or directly to {{product.observability}}.
+
+The only requirement is that collectors deployed on edge environments send data using valid OpenTelemetry Protocol (OTLP) to Elastic Cloud (via managed OTLP endpoint) or to the OTLP receiver of a gateway EDOT collector for self-managed deployments.
 
 While any OTLP-compatible collector works at the edge, using EDOT provides a more streamlined experience with:
 
@@ -45,12 +47,12 @@ While any OTLP-compatible collector works at the edge, using EDOT provides a mor
 
 The need for an EDOT Collector in gateway mode depends on your Elastic deployment type:
 
-**{{serverless-full}} and {{ech}}**: Edge collectors can send OTLP data directly to the [Managed OTLP Endpoint](/reference/motlp.md) without requiring a Gateway Collector. The Managed OTLP Endpoint handles all necessary preprocessing and data transformation.
+**{{serverless-full}} and {{ech}}**: Edge collectors can send OTLP data directly to the [Managed OTLP Endpoint](/reference/motlp.md) without requiring a Gateway Collector. The Managed OTLP Endpoint provides a managed durable and resilient ingestion layer.
 
-**Self-managed, ECE, and ECK deployments**: An EDOT Collector in Gateway mode is required between your edge collectors and {{es}}. The gateway Collector performs essential preprocessing, including:
+**Self-managed, ECE, and ECK deployments**: An EDOT Collector in Gateway mode is required as part of the stack, this collector will expose the OTLP endpoint that collectors deployed at the edge can send data to. The gateway Collector handles essential preprocessing, including:
 
 - Data enrichment and transformation.
-- Metrics aggregation.
+- Metrics aggregation for traces and logs which improves APM UI performance with lower latency.
 - Format conversion for optimal storage in {{es}}.
 
 :::{note}

docs/reference/architecture/k8s.md

@@ -19,21 +19,23 @@ The recommended OTel architecture for Kubernetes clusters includes a set of Open
 
 ## Daemon form
 
-The Collector in Daemon form is deployed on each Kubernetes node as an [edge collector](index.md#understanding-edge-deployment) (close to your data sources) to collect node-local logs and host metrics.
+The Collector as a DaemonSet resource kind, deploys an instance on each Kubernetes node as an [edge collector](index.md#understanding-edge-deployment) (close to your data sources) to collect node-local logs and host metrics.
 
-The daemon collector also receives telemetry from applications instrumented with OTel SDKs and running on corresponding nodes.
+The DaemonSet collectors also can funnel and enrich telemetry from applications instrumented with OTel SDKs and running on corresponding nodes.
 
 That Collector enriches the application telemetry with resource information such as host and Kubernetes metadata.
 
 All data is then sent through OTLP to the OTel or EDOT Collector in gateway mode.
 
-## Cluster form
+## Cluster Collector
 
-The Collector in Cluster form collects Kubernetes cluster-level metrics and sends them to the OTel or EDOT Gateway Collector using OTLP.
+The Cluster collector is a Deployment resource kind that collects Kubernetes cluster-level metrics and sends them to the OTel or EDOT Gateway Collector using OTLP.
+
+This instance of the collector helps with collecting cluster level metrics which otherwise would be duplicated by the DaemonSet instances.
 
 ## Gateway form
 
-The OTel or EDOT Collector in gateway form gathers the OTel data from all other collectors and ingests it into the Elastic backend.
+The OTel or EDOT Collector gateway deployed on the edge Kubernetes environment is not an ingestion layer to Elastic, it centralizes OTel data from all other collectors to help define a unified data pipeline sending OTLP data into the Elastic backend corresponding OTLP endpoint.
 
 For self-managed, ECE, and ECK deployment models the gateway Collector does some additional preprocessing of data.
 
@@ -69,11 +71,11 @@ Alternatively, you can run a self-hosted EDOT Collector in gateway mode. The gat
 
 ### Self-managed
 
-With a self-managed scenario the gateway Collector ingests data directly into the self-managed {{es}} instance.
+With a self-managed deployment the gateway Collector ingests data directly into the self-managed {{es}} instance.
 
 ![K8s-self-managed](../images/arch-k8s-self-managed.png)
 
-The gateway Collector does some preprocessing and aggregation of OTel data before ingesting it into {{es}}.
+The gateway Collector processes APM data and logs to improve latency on solution UIs before is ingested into {{es}}.
 
 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](elastic-agent://reference/edot-collector/custom-collector.md) containing the [required components and preprocessing pipelines](elastic-agent://reference/edot-collector/config/default-config-k8s.md#direct-ingestion-into-elasticsearch).