> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mezmo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenTelemetry Source

## Description

You can send your logs, metrics and traces to a Mezmo Pipeline via any OTLP compliant sender.

<info>
  Mezmo currently requires that you use the HTTP transport for your payload, not the standard gRPC transport mechanism, to send in data via OTLP
</info>

<Note>
  A pipeline can include only one OpenTelemetry Source because it reads a shared account-wide data stream. You can still add an OpenTelemetry Source to other pipelines. Mezmo enforces this whether you add the source through the Mezmo Web App, the Pipeline API, Terraform, cloning a pipeline, or importing a pipeline manifest. If you try to add a second OpenTelemetry Source to the same pipeline, Mezmo rejects the request with an HTTP 409 error and the code `ERR_SHARED_SOURCE_DUPLICATE`. See [Set Up Pipeline Sources](/telemetry-pipelines/set-up-pipeline-sources) and the [Error Code Reference](/telemetry-pipelines/error-code-reference) for details.
</Note>

## Configuration

There is no specific configuration values needed when adding this source to your pipeline. The OpenTelemetry source uses a shared endpoint to ingest data. It will route data to your pipeline based on your [Ingestion key](/docs/ingestion-key#ingestion-keys) (`apikey`).

You can obtain this key under Setting | API Keys In App.

### What you will need when configuring your OTEL collector

| Option | Description |
| - | - |
| url / endpoint | [https://logs.mezmo.com/otel](https://logs.mezmo.com/otel) |
| apiKey | aka: Ingestion Key. Token used for authorization for your OTLP source |

### OpenTelemetry Collector Configuration

To configure an existing OTel collector to export to Mezmo, you can add the following to your exporters section of your OTel Collector config file:

```yaml theme={null}
exporters:
  otlphttp/mezmo:
    endpoint: "https://logs.mezmo.com/otel"
    compression: gzip
    headers:
      apikey: "<YOUR_INGESTION_KEY>"
      
...

 service:
    pipelines:
      logs:
        receivers:  [otlp]
        processors: [memory_limiter, batch]
        exporters:  [otlphttp/mezmo]
      metrics:
        receivers:  [otlp]
        processors: [memory_limiter, batch]
        exporters:  [otlphttp/mezmo]
      traces:
        receivers:  [otlp]
        processors: [memory_limiter, batch]
        exporters:  [otlphttp/mezmo]
```

<info>
  The endpoint accepts gzip-compressed OTLP payloads in both protobuf and JSON format. You can reduce network bandwidth by setting `compression: gzip` on your `otlphttp` exporter, as shown above. The endpoint also accepts uncompressed payloads.
</info>

<warning>
  The endpoint in the exporters configuration must exactly match the URL above. You don't need to specify the `/v1/[type]` path, this is done automatically by the collector
</warning>

For more details, visit [OpenTelemetry Collector](./otel-collector)

### Connection Confirmation

Some OTLP clients test the connection during setup by sending an empty payload, so sending a request whose JSON body parses to an empty object (`{}`) lets you confirm connectivity to the endpoint without publishing any records. For example, SAP Cloud Integration's External Logging activation sends an empty payload during connection setup.

When the endpoint accepts such a request, it returns HTTP status `207` with the following response body, and no records are processed or published:

```json theme={null}
{"status":"ok","message":"Connection confirmed, no records processed."}
```

A successful publish of real records returns HTTP status `200` instead; `207` appears only for this connection-confirmation case.

<Note>
  The body must parse to an empty JSON object. `{}` with surrounding whitespace works, but a zero-byte body, a whitespace-only body with no braces, and an empty JSON array (`[]`) are still rejected with HTTP status `400`.
</Note>

## Payload Size

The endpoint accepts large OTLP HTTP payloads, including large multi-line batches. Mezmo automatically splits large batches, so you no longer need to keep your batches under a small size cap.

<Note>
  An individual event must still fit under the maximum message size. If a single event is larger than that limit, Mezmo rejects the request with an HTTP 413 error and the message `Request contains events larger than the maximum message size`. Nothing from the request is published when this happens, so you can safely retry after reducing the event size. See the [Error Code Reference](/telemetry-pipelines/error-code-reference) for details.
</Note>