OpenTelemetry Protocol (OTLP): The Universal Adapter for Telemetry
OTLP is the universal adapter for observability, providing a single vendor-neutral protocol for traces, metrics, and logs. Use it to send data from an OpenTelemetry SDK to a collector.
WHY IT EXISTS: Before OpenTelemetry, every monitoring vendor had its own data format and agent. This created vendor lock-in, making it difficult to switch observability backends. OTLP was created as a standard, open-source "wire protocol" to solve this problem by unifying how telemetry data is transmitted.
THE MENTAL MODEL: Think of OTLP as the USB-C of observability. Instead of needing a different proprietary cable (agent/protocol) for each device (monitoring vendor), OTLP provides a single, unified connector for sending all your telemetry data—traces, metrics, and logs.
HOW IT WORKS: OTLP is a specification that defines the data model for telemetry signals and how they are encoded for transport. It uses Protocol Buffers (Protobuf) for efficient data serialization and can be sent over gRPC (for performance) or HTTP. An application's OTel SDK uses an OTLP exporter to send this data to a receiver, like the OTel Collector.
WHEN TO USE IT: Use OTLP as the default choice for getting data out of an OpenTelemetry-instrumented service. It's the native language of the OTel ecosystem, ensuring maximum compatibility and feature support when sending data to an OTel Collector or a modern observability platform that has adopted the standard.
WHEN NOT TO USE IT: You might use a different exporter if your destination only supports a legacy format and you cannot deploy a collector to handle translation. For example, if you must export directly to a system that only scrapes Prometheus metrics, you would use the Prometheus exporter instead of OTLP. However, the recommended pattern is to send OTLP to a collector and let the collector handle the translation.
ONE CANONICAL EXAMPLE: A microservice written in Go uses the OTel SDK to generate traces. The SDK is configured with an OTLP/gRPC exporter that points to an OTel Collector agent running on the same host. The collector receives the trace data via OTLP, batches it, adds metadata, and then uses a different exporter to forward the data to a cloud-based APM tool for analysis and storage.
Read the original → opentelemetry.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.