What Is OTLP (OpenTelemetry Protocol)?

Last verified on Nov 8, 2026.

OTLP, the OpenTelemetry Protocol, is the wire format OpenTelemetry uses to send traces, metrics, and logs from an application or Collector to a backend. The spec is stable for all three signals. If a tool says it accepts OTLP, you can point any OpenTelemetry SDK at it without a custom exporter.

Transports and Ports

OTLP has two transports, and a server may accept both.

OTLP/HTTP sets Content-Type: application/x-protobuf for binary Protobuf and application/json for JSON-encoded Protobuf. The client may gzip the body, in which case it must send Content-Encoding: gzip.

HTTP Paths

Each signal posts to its own path, appended to the base URL:

So a base of https://collector.example.com:4318 receives traces at https://collector.example.com:4318/v1/traces.

Configuring an Exporter

SDKs read standard environment variables. OTEL_EXPORTER_OTLP_ENDPOINT sets one endpoint for every signal, and OTEL_EXPORTER_OTLP_PROTOCOL picks grpc, http/protobuf, or http/json. The default is SDK-dependent, typically http/protobuf or grpc. Signal-specific variables override the shared one:

export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4318/v1/traces

Note the difference: with a signal-specific variable you give the full URL including the path, while for the shared variable the SDK adds /v1/traces and the other paths itself in HTTP mode. For gRPC, the docs say not to append signal paths at all, because the exporter uses the protobuf service method for each signal.

OTLP Errors and Retries

The spec splits server errors into two groups. Retryable errors mean the server could not process the data right now, and the client may retry the same data. Non-retryable errors, such as a request that cannot be deserialized, mean the client must drop that data. For HTTP, an overloaded server should answer 429 Too Many Requests or 503 Service Unavailable. A server can also accept part of a batch: it fills in partial_success, and the client must not retry that request.

Common Problems

• Wrong port or protocol. Port 4317 speaks gRPC and 4318 speaks HTTP by default, so sending one protocol to the other port will not work. Match the protocol variable to the port.
• Wrong path. A signal-specific variable takes the full URL, so a base URL with no /v1/traces sends spans to the wrong place. The shared variable does the opposite: give it only the base, or the path gets doubled.
• Dropped batches. Non-retryable responses mean data is gone, so watch your SDK's exporter logs.
• Nothing in the backend. Confirm the URL and protocol first, then send one request end to end. The OpenTelemetry docs recommend a Collector next to your service because it handles retries, batching, and encryption.

OTLP in Sazabi

Sazabi, an AI-native observability and security platform, acts as an OTLP/HTTP destination. For traces, set OTEL_EXPORTER_OTLP_TRACES_ENDPOINT to the intake URL copied from your project, which already ends in /v1/traces, and set OTEL_EXPORTER_OTLP_TRACES_PROTOCOL to http/protobuf. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run. From a Collector, add an otlphttp exporter. The OpenTelemetry traces integration walks through it.