What is OTLP (OpenTelemetry Protocol)?

OTLP (OpenTelemetry Protocol) is the wire protocol of the OpenTelemetry project: a standardized, vendor-neutral format for transmitting traces, metrics, and logs between applications, collectors, and backends. It is the piece that makes OpenTelemetry’s promise real — instrument once, send anywhere.

Why OTLP exists

Before OTLP, every signal had its own protocol zoo: Jaeger and Zipkin formats for traces, Prometheus exposition and remote write for metrics, syslog and vendor APIs for logs. Every pairing of agent and backend needed an adapter. OTLP replaces the zoo with a single protocol covering all three signals, with stable protobuf schemas, defined retry/backpressure semantics, and two transports:

• OTLP/gRPC — default port 4317; efficient, streaming, the common choice service-to-collector
• OTLP/HTTP — default port 4318; protobuf or JSON over plain HTTP, friendlier to proxies, load balancers, and browsers

How OTLP fits the pipeline

A typical flow: OpenTelemetry SDKs in your services export OTLP to an OpenTelemetry Collector, which processes the data and exports OTLP again to one or more backends. Because both hops speak the same protocol, you can insert, remove, or fan out pipeline stages without touching application code — and switch backends by changing one exporter endpoint.

What OTLP means for vendor lock-in

OTLP moved the industry’s center of gravity: instrumentation is no longer a vendor asset. If your telemetry leaves the building as OTLP, any OTLP-native backend can receive it, and migrations become configuration changes rather than re-instrumentation projects.

OTLP in OpenObserve

OpenObserve is an OTLP-native backend: it exposes gRPC (4317) and HTTP (4318) endpoints and ingests traces, metrics, and logs directly from SDKs or collectors — no proprietary agent, no format translation. See the OpenTelemetry solution page for setup in minutes.