--- title: "Glossary: OTLP" canonical_url: "https://tokenobserve.com/glossary/otlp" published: 2026-09-02 last_updated: 2026-10-21 --- # Glossary: OTLP OTLP, the OpenTelemetry Protocol, is the vendor-neutral wire format OpenTelemetry uses to carry traces, metrics and logs from an instrumented process to a collector or a backend. Its payloads are Protocol Buffers messages sent over gRPC or HTTP, as binary protobuf or its canonical JSON mapping, and it is a one-way export: the receiver acknowledges what it accepted and names what it rejected, and never sends telemetry back. ## Also called - OpenTelemetry Protocol - OTLP/HTTP - OTLP over gRPC - OTel protocol ## In practice The problem OTLP solves is that telemetry used to be inseparable from its destination. Every vendor shipped an agent and a format, so changing backend meant re-instrumenting the application. OTLP splits the two: the code emits one format, and where it goes is a configuration change. An export carries records grouped under a Resource — the attributes describing what produced them, of which service.name is the one everything indexes on — and under an instrumentation Scope naming the library that emitted them. Three signals are stable: spans for traces, data points for metrics, and log records; profiling is a later addition and is not yet in the same state. The transport details matter more than they look, because collectors act on them mechanically. gRPC defaults to port 4317 and HTTP to 4318, with the HTTP paths /v1/traces, /v1/metrics and /v1/logs. Content types are application/x-protobuf for binary and application/json for the protobuf JSON mapping, and a correct receiver answers in whichever encoding the request used. A partially bad batch is not rejected whole: the response carries a partial-success object counting rejected spans, data points or log records with an error message, so 3 malformed spans do not lose the other 4,997. And status codes carry a contract about retry — 400 and 415 are non-retryable, so an exporter drops the batch, while 429, 502, 503 and 504 are retryable, so it keeps the batch and honours Retry-After. Returning 400 where 503 belongs silently destroys the record; returning 503 where 400 belongs wedges the exporter’s queue on a batch that will never succeed. For anyone using telemetry as evidence rather than as debugging output, the governing property of OTLP is that everything in the payload is self-reported. The resource attributes naming the service, the host, the deployment environment and, in some instrumentations, the end user, are all configuration on the sending machine. A receiver that files a record under a subject because the payload said so has built a system where any credential that can reach the port can write any subject’s history — which is materially worse than having no history, because a fabricated record is believed. Attribution has to come from the credential that carried the request, with the resource attributes kept as evidence about the exporter’s configuration rather than as fact about the world. The second limit is about timing and cooperation. Telemetry arrives after the event, from a process the receiver does not control, and it can be sampled, batched, dropped on backpressure, or never sent — head sampling at one per cent is a normal production setting, and it means ninety-nine of every hundred spans do not exist anywhere. That makes OTLP an accurate record of what a cooperating process chose to report, and a poor record of what an uncooperative one did. The vocabulary worth keeping is the distinction between an event that was enforced, meaning a decision was taken in the request path and could have refused, and one that was merely recorded. Running a policy engine over ingested telemetry produces blocked verdicts against actions that already completed, which reads as enforcement in a report and is not — a false-enforcement reading that is more damaging than a visible gap. Two mechanics follow from that in a receiver used for evidence. Redaction at ingest is irreversible rather than tokenised, because there is no downstream conversation to keep coherent and a reversible placeholder for a credential is a credential. And every bound in the decoder is explicit — records per export, traces opened per export, attribute nesting, string length, protobuf field count — because a telemetry endpoint accepts input from processes it does not administer, and an unbounded decoder on such an endpoint is a denial-of-service surface wearing an observability label. ## Example: The attribute that must not be believed An exporter sends a log record whose resource attributes say service.name=payments-agent and enduser.id=alice@example.com. Both values came from environment variables on the sending machine, which the sending machine’s owner controls. If the receiver files that record under Alice’s history because the payload asserted it, then any holder of any valid ingest credential can write any person’s history, and the resulting record is as convincing as a real one. The correct behaviour is to attribute the write to the bearer credential that carried the request, and to store the resource attributes as what they are — a claim about the exporter’s configuration, recorded as a claim. This is the same discipline as never reading a seat identifier out of a request body when the credential already names one. ## Routinely confused with OpenTelemetry: OpenTelemetry is the whole project: an API, SDKs in a dozen languages, semantic conventions for attribute names, and the Collector. OTLP is only its wire protocol. You can instrument with OpenTelemetry SDKs and export in a vendor’s proprietary format, and you can emit OTLP from something that uses no OpenTelemetry SDK at all. An audit record: A distributed trace is produced by the system it describes, for the purpose of debugging it, and is routinely sampled away. An audit record is produced at a decision point, is never sampled, and is meant to stand as evidence against the party that produced it. A trace tree written by the process under examination is a description, not testimony. The OpenTelemetry Collector: The Collector is a deployable binary that receives, processes and forwards telemetry; OTLP is one of the formats it speaks, and the one it speaks by default in both directions. A backend that accepts OTLP directly needs no Collector, and a Collector can receive Jaeger or Prometheus and emit OTLP.