---
title: Elastic Cloud Managed OTLP Endpoint (mOTLP)
description: Reference documentation for the Elastic Cloud Managed OTLP Endpoint.
url: https://www.elastic.co/elastic/docs-builder/docs/3028/reference/opentelemetry/motlp
products:
  - Elastic Cloud Serverless
  - Elastic Distribution of OpenTelemetry Collector
  - Elastic Observability
applies_to:
  - Serverless Observability projects: Generally available
  - Serverless Security projects: Generally available
  - Elastic Cloud Hosted: Generally available
---

# Elastic Cloud Managed OTLP Endpoint (mOTLP)
The Elastic Cloud Managed OTLP Endpoint allows you to send OpenTelemetry data directly to Elastic Cloud using the OTLP protocol.
The endpoint provides a resilient ingestion layer that works seamlessly with serverless autoscaling and offloads ingestion processing from Elastic Cloud Hosted clusters.
<important>
  The Elastic Cloud Managed OTLP Endpoint endpoint is not available for Elastic [self-managed](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/deploy-manage/deploy/self-managed), [ECE](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/deploy-manage/deploy/cloud-enterprise), or [ECK](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/deploy-manage/deploy/cloud-on-k8s) clusters. To send OTLP data to any of these cluster types, deploy and expose an OTLP-compatible endpoint using the [EDOT Collector as a gateway](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/reference/edot-collector/modes#edot-collector-as-gateway).
</important>


## Prerequisites

To use the Elastic Cloud Elastic Cloud Managed OTLP Endpoint you need the following:
- An Elastic Cloud Serverless project or an Elastic Cloud Hosted (ECH) deployment.
- An OTLP-compliant shipper capable of forwarding logs, metrics, or traces in OTLP format. This can include:
  - [OpenTelemetry Collector](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/reference/edot-collector) (EDOT, Contrib, or other distributions)
- [OpenTelemetry SDKs](https://www.elastic.co/elastic/docs-builder/docs/3028/reference/opentelemetry/edot-sdks) (EDOT, upstream, or other distributions)
- [EDOT Cloud Forwarder](https://www.elastic.co/elastic/docs-builder/docs/3028/reference/opentelemetry/edot-cloud-forwarder)
- Any other forwarder that supports the OTLP protocol.

You don't need APM Server when ingesting data through the Managed OTLP Endpoint. The APM integration (`.apm` endpoint) is a legacy ingest path that translates OTLP telemetry to ECS, whereas Elastic Cloud Managed OTLP Endpoint natively ingests OTLP data.

## Send data to the Managed OTLP Endpoint

To send data to Elastic through the Elastic Cloud Managed OTLP Endpoint, follow the [Send data to the Elastic Cloud Managed OTLP Endpoint](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/solutions/observability/get-started/quickstart-elastic-cloud-otel-endpoint) quickstart.

### Find your Elastic Cloud Managed OTLP Endpoint endpoint

To retrieve your Elastic Cloud Managed OTLP Endpoint endpoint address and API key, follow these steps:
<applies-switch>
  <applies-item title="serverless:" applies-to="Elastic Cloud Serverless: Generally available">
    1. In Elastic Cloud, create an Observability project or open an existing one.
    2. Go to **Add data**, select **Applications** and then select **OpenTelemetry**.
    3. Copy the endpoint and authentication headers values.
    Alternatively, you can retrieve the endpoint from the **Manage project** page and create an API key manually from the **API keys** page.
  </applies-item>

  <applies-item title="ech:" applies-to="Elastic Cloud Hosted: Generally available">
    1. Log in to the Elastic Cloud Console.
    2. From the home page, find your deployment in **Hosted deployments**, and select **Manage**. Or, on the **Hosted deployments** page, select your deployment.
    3. In the **Application endpoints, cluster and component IDs** section, select **Managed OTLP**.
    4. Copy the public endpoint value.
  </applies-item>
</applies-switch>


### Configure SDKs to send data directly

To configure OpenTelemetry SDKs to send data directly to the Elastic Cloud Managed OTLP Endpoint, set the `OTEL_EXPORTER_OTLP_ENDPOINT` and `OTEL_EXPORTER_OTLP_HEADERS` environment variables.
For example:
```bash
export OTEL_EXPORTER_OTLP_ENDPOINT="https://<motlp-endpoint>"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <key>"
```


### Routing logs to dedicated datasets

You can route logs to dedicated datasets by setting the `data_stream.dataset` attribute on the log record. This attribute is used to route the log to the corresponding dataset.
For example, if you want to route the EDOT Cloud Forwarder logs to custom datasets, you can add the following attributes to the log records:
```yaml
processors:
  transform:
    log_statements:
      - set(log.attributes["data_stream.dataset"], "aws.cloudtrail") where log.attributes["aws.cloudtrail.event_id"] != nil
```

You can also set the `OTEL_RESOURCE_ATTRIBUTES` environment variable to set the `data_stream.dataset` attribute for all logs. For example:
```bash
export OTEL_RESOURCE_ATTRIBUTES="data_stream.dataset=app.orders"
```


## OTLP client configuration

When using OpenTelemetry collectors to send data to the Elastic Cloud Managed OTLP Endpoint, configure the OTLP exporter to leverage an in-memory queue and optimized batching defaults. This improves throughput, minimizes data loss, and maintains low end-to-end latency.
```yaml
exporters:
  otlp/elastic:
    endpoint: "${MOTLP_ENDPOINT}"
    headers:
      Authorization: "ApiKey <key>"
    sending_queue:
      enabled: true
      sizer: bytes
      queue_size: 50_000_000
      block_on_overflow: true
      batch:
        flush_timeout: 1s
        min_size: 1_000_000
        max_size: 4_000_000
```

The key settings are:
- **`sending_queue`**: Enables an in-memory queue with byte-based sizing (`sizer: bytes`) and a 50 MB capacity. `block_on_overflow: true` applies backpressure instead of dropping data when the queue is full.
- **`batch`**: Controls how queued data is batched before export. A `flush_timeout` of 1 second ensures low latency, while `min_size` (1 MB) and `max_size` (4 MB) keep payloads within the Elastic Cloud Managed OTLP Endpoint limits. Refer to the [Payload too large](/elastic/docs-builder/docs/3028/reference/opentelemetry/motlp/troubleshooting#error-payload-too-large) troubleshooting section for details on payload size limits.


## Reference architecture

This diagram shows data ingest using Elastic Distribution of OpenTelemetry and the Elastic Cloud Managed OTLP Endpoint:
![mOTLP Reference architecture](https://www.elastic.co/elastic/docs-builder/docs/3028/reference/opentelemetry/images/motlp-reference-architecture.png)

Telemetry is stored in Elastic in OTLP format, preserving resource attributes and original semantic conventions. If no specific dataset or namespace is provided, telemetry would be routed to the generic data streams: `traces-generic.otel-default`, `metrics-generic.otel-default`, and `logs-generic.otel-default`.
For a detailed comparison of how OTel data streams differ from classic Elastic APM data streams, refer to [OTel data streams compared to classic APM](https://www.elastic.co/elastic/docs-builder/docs/3028/reference/opentelemetry/compatibility/data-streams).

## Failure store

<applies-to>
  - Elastic Stack: Generally available since 9.1
</applies-to>

The Elastic Cloud Managed OTLP Endpoint endpoint is built for high availability, but some failures can still prevent telemetry events from being written to your Elasticsearch cluster (for example, ingest pipeline errors or mapping conflicts).
To protect data in these cases, Elastic Cloud Managed OTLP Endpoint uses the [Failure store](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/manage-data/data-store/data-streams/failure-store). For Elastic Cloud Managed OTLP Endpoint data streams, the failure store is always enabled.
When indexing fails, the original documents are written to a dedicated failure index instead of being dropped. This keeps ingestion resilient and gives you a recovery path for partial or failed sends.
You can inspect and triage these documents from **Data Set Quality**. Refer to [Data set quality](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/solutions/observability/data-set-quality-monitoring).

## Limitations

The following limitations apply when using the Elastic Cloud Managed OTLP Endpoint:
- Universal Profiling is not available.
- Only supports histograms with delta temporality. Cumulative histograms are dropped.
- Latency distributions based on histogram values have limited precision due to the fixed boundaries of explicit bucket histograms.
- Tail-based sampling (TBS) is not available. The Elastic Cloud Managed OTLP Endpoint does not provide centralized hosted sampling. If you need tail-based sampling, configure it on the edge using the [Tail Sampling Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor) in your EDOT or OpenTelemetry Collector before sending data to the endpoint.
- In Elastic Cloud Hosted deployments:
  - [IP filters](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/deploy-manage/security/ip-filtering-cloud) do not apply to the managed endpoint.
- The endpoint is not available over a [private connection](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/deploy-manage/security/private-connectivity). When private connectivity is configured, the public managed endpoint is still available.


## Billing

For more information on billing, refer to [Elastic Cloud pricing](https://www.elastic.co/pricing/serverless-observability).