Lexicon
OTLP
OTLP is the OpenTelemetry Protocol, the wire format for logs, metrics, and traces. How it works, gRPC vs HTTP, and why truly native OTLP ingestion matters.
Definition
OTLP is the OpenTelemetry Protocol, the standard wire format for sending logs, metrics, and traces between the components of an OpenTelemetry pipeline. SDKs export it, Collectors receive and forward it, and backends ingest it, all speaking one language for all three signals.
What it means in observability
Before OTLP, every signal and every vendor had its own transport: Jaeger and Zipkin formats for traces, StatsD and Prometheus exposition for metrics, syslog and a dozen shipper formats for logs. OTLP collapsed that sprawl into one protocol with one data model. In practice, OTLP support has become the compatibility test for the whole observability market. If a tool can send or receive OTLP, it can participate in an OpenTelemetry pipeline, and if it cannot, it sits outside the ecosystem. For engineering teams that makes OTLP the safest possible export target: point your telemetry at an OTLP endpoint and you keep the freedom to change what sits behind it.
How it works in practice
OTLP payloads are defined in protocol buffers and travel over two transports: gRPC, conventionally on port 4317, and HTTP with protobuf or JSON encoding, conventionally on port 4318. An SDK can export OTLP directly to a backend or send it to a Collector first for batching, enrichment, and routing. The protocol carries full resource context alongside every signal, which is what lets a backend know that a given span, metric point, and log record all came from the same pod of the same service in the same region. It also defines retry and backpressure semantics, so senders know how to behave when an endpoint is slow or briefly unavailable.
Where it gets hard
The common friction points are operational. gRPC does not always pass cleanly through proxies and load balancers, which is why many teams fall back to OTLP over HTTP. Payload and batch sizing need attention at volume, since oversized exports get rejected and undersized ones waste connections. Then there is the subtle trap: accepting OTLP is not the same as storing it. Many platforms take OTLP at the edge, then convert it into a proprietary internal model, dropping or renaming attributes along the way. What you sent and what you can query end up being different things.
Where Tsuga fits
OTLP is Tsuga's native ingestion format, not a compatibility layer. Telemetry arrives as OTLP and keeps its OpenTelemetry shape all the way to query, with resource context and attribute names intact. There is no translation step where fidelity quietly leaks away.
Related terms
- OpenTelemetryOpenTelemetry is an open source framework for generating, collecting, and exporting telemetry: the logs, metrics, and traces that describe how software behaves in production.
- OpenTelemetry CollectorThe OpenTelemetry Collector is a standalone process that receives telemetry from applications and infrastructure, transforms it, and exports it to one or more destinations.
- SDKAn SDK, or software development kit, is a set of libraries and tools for building against a platform or standard.
- Semantic conventionsSemantic conventions are OpenTelemetry's standard vocabulary: the agreed names, types, and values for the attributes that describe telemetry.