﻿---
title: Hosts and VMs environments
description: Recommended EDOT architecture for host or virtual machine environments.
url: https://www.elastic.co/docs/reference/opentelemetry/architecture/hosts_vms
products:
  - Elastic Cloud Serverless
  - Elastic Distribution of OpenTelemetry Collector
  - Elastic Observability
---

# Hosts and VMs environments

On host or virtual machine environments, deploy local, per-host OpenTelemetry Collector instances, here referred to as OTel Collector in Agent Mode.
![VM-Edge](https://www.elastic.co/docs/reference/opentelemetry/images/arch-vm-edge.png)
These collectors 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.


## Deployment scenarios

See the recommended architectures per Elastic deployment scenarios:
<note>
  Elastic's Observability solution is technically compatible with edge setups that are fully based on contrib OTel components as long as the ingestion path follows the recommendations outlined in the following sections.
</note>


### Elastic Cloud Serverless

Elastic Cloud Serverless provides a [Managed OTLP Endpoint](https://www.elastic.co/docs/reference/opentelemetry/motlp) for ingestion of OpenTelemetry data.
![VM-Serverless](https://www.elastic.co/docs/reference/opentelemetry/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](https://www.elastic.co/docs/reference/opentelemetry/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](https://staging-website.elastic.co/docs/reference/edot-collector/custom-collector).
<note>
  The EDOT Gateway Collector does not send data through Elastic's Integration / APM Server on ECH to ingest data into Elasticsearch.
</note>

<important>
  If self-managing an EDOT Gateway is not a valid option for you, refer to [Elastic's classic ingestion path for OTel data on ECH](https://staging-website.elastic.co/docs/solutions/observability/apm/opentelemetry).
</important>


### 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 into the self-managed Elastic Stack.
![VM-self-managed](https://www.elastic.co/docs/reference/opentelemetry/images/arch-vm-self-managed.png)
<note>
  Compared to [Elastic's classic ingestion paths](https://staging-website.elastic.co/docs/solutions/observability/apm/opentelemetry) for OTel data, with the EDOT Gateway Collector there is no need for an APM Server anymore.Refer to [EDOT data streams compared to classic APM](https://www.elastic.co/docs/reference/opentelemetry/compatibility/data-streams) for a detailed comparison of data streams, mappings, and storage models.
</note>
