What Is OTLP (OpenTelemetry Protocol)?
OTLP is the standard language that OpenTelemetry components use to send traces, metrics, and logs to each other and to your monitoring tools. This guide explains it from zero: what it defines, how its two transports differ, how data is structured and delivered reliably, and how to use it well.
Think about how goods travel around the world. Not long ago, every shipping company packed cargo in its own sizes of crates and barrels, and every port needed special equipment for each one. Loading and unloading were slow, expensive, and error-prone. Then the standard shipping container arrived. Every container had the same dimensions and the same corner fittings, so any ship, train, or truck could carry any container, and any port could handle it. Trade exploded, because moving goods stopped being a puzzle. OTLP is the shipping container of telemetry. It is one agreed way to package and deliver traces, metrics, and logs, so that any application, any Collector, and any backend can pass them along without special adapters.
1The Big Picture: Telemetry Has to Travel
Data produced in one place is only useful if it can reach another place intact.
Software produces a constant stream of information about its own behavior. Traces show the path of requests, metrics summarize numbers over time, and logs record individual events. Together this information is called telemetry. But telemetry created inside a running program is useless until someone can look at it. It has to leave the program, cross a network, and arrive at a system that stores it and lets people search it. That journey is where a protocol comes in.
A protocol is simply an agreement about how two parties talk. It says what the messages look like, how they are sent, how the receiver replies, and what happens when something goes wrong. Without a shared protocol, every sender would need a custom connection to every receiver. If you have ten kinds of applications and ten kinds of monitoring tools, you would need a hundred different connections. With one shared protocol, you need only ten plus ten, because everyone speaks the same language.
Many Private Languages
Each tool invented its own format and connection style, so mixing tools meant writing converters.
Lock-in and Duplication
Changing tools meant changing instrumentation, and running two tools meant sending data twice in two formats.
One Shared Language
Applications speak one protocol, and any compatible tool can receive it.
Freedom to Choose
You can change or add backends by changing a destination, not by rewriting how applications report.
Think of electrical plugs around the world. A traveler with a drawer full of different plugs and adapters is always one step away from being unable to charge a phone. If every country used the same socket, nobody would need adapters at all. OTLP aims to be that universal socket for telemetry.
OpenTelemetry is an open-source, vendor-neutral project that standardizes how telemetry is created and moved. OTLP is the part that standardizes the moving. Many monitoring products now accept OTLP directly.
2What Is OTLP?
OTLP is the general-purpose protocol OpenTelemetry uses to deliver telemetry from one place to another.
OTLP stands for OpenTelemetry Protocol. It is a specification that describes how telemetry data is encoded, how it is transported over a network, and how delivery is acknowledged and retried. It is designed to carry all the main signals, traces, metrics, and logs, using the same overall approach, and it is also being extended to carry newer signals such as profiles.
OTLP is used at several points along the telemetry journey. An application’s OpenTelemetry library uses it to send data out. The OpenTelemetry Collector uses it to receive data and to send data onward. And many monitoring backends accept it directly, so you can send data to them without a translation step. This makes OTLP the common thread through the whole pipeline.
OTLP is like the rules of a courier service. It says how parcels must be packed, which trucks can carry them, what receipt the recipient must give, and what to do if the recipient is not home. Everyone who follows the rules can send parcels to everyone else.
What OTLP Is Not
It helps to be clear about what OTLP does not do. It is not a storage system, and it does not draw charts. It is not an instrumentation library, so it does not create telemetry by itself. And it is not the only way to move telemetry: older protocols still exist and the Collector can translate between them and OTLP. OTLP is purely the delivery agreement, the part that moves data from point A to point B in a standard shape.
OTLP describes the journey, not the content creation. The OpenTelemetry libraries create the data; OTLP carries it.
3The Three Things OTLP Defines
A good protocol answers three questions: what do messages look like, how do they travel, and what happens on arrival?
Every protocol, from the postal service to the internet, has to settle a few basic matters. OTLP settles three, and understanding them gives you a clear mental map of everything else in this guide.
Encoding
How the data is written down: the structure of a trace, a metric, or a log record, and the format used to turn it into bytes.
Transport
How the bytes travel across the network: over gRPC or over HTTP, to which addresses, with which headers.
Delivery Behavior
How success and failure are reported, which failures should be retried, and how a busy receiver can ask senders to slow down.
flowchart LR
A["Application with OpenTelemetry library"] -->|"OTLP"| B["Collector"]
B -->|"OTLP"| C["Backend that accepts OTLP"]
A -->|"OTLP directly"| C
How the Layers Fit Together
Imagine sending a gift. The encoding is how you wrap it and write the address. The transport is which delivery company carries it. The delivery behavior is the tracking, the signature on arrival, and the rule that the courier tries again tomorrow if nobody is home. OTLP defines all three, so a sender and a receiver that both follow OTLP can exchange telemetry successfully even if they were built by different teams in different languages.
Because the three layers are separate ideas, you can change one without disturbing the others. For example, switching from the gRPC transport to the HTTP transport does not change the structure of the data being carried.
4Protocol Buffers: The Language Under the Hood
OTLP data is described using a technology called Protocol Buffers, often shortened to protobuf.
To write data down for travel, OTLP uses Protocol Buffers, a widely used technology created for efficiently describing and encoding structured data. With protobuf, you first write a schema, which is a precise description of what each message contains: the names, types, and numbers of every field. From that schema, tools can automatically generate code in many programming languages to build and read the messages. OTLP’s schema is published as a shared project that all OpenTelemetry libraries use.
Why a Schema Helps
Compact Size
Messages are encoded in a tight binary form that is usually much smaller than the same data written as text.
Fast to Process
Reading and writing binary data is quick, which matters when millions of records pass through every minute.
Many Languages
The same schema generates code for many languages, so a Java sender can talk to a Go receiver without surprises.
Safe Evolution
New fields can be added over time without breaking older programs, which simply ignore fields they do not recognize.
A schema is like a printed form with numbered boxes. Everyone who receives the form knows that box three is the date and box seven is the amount. If a later version of the form adds box eight, older offices simply skip it and carry on. The numbers in the boxes are what keep everything compatible, not the labels.
Human-Readable Alternative
Binary data is efficient, but humans cannot read it, which makes quick experiments harder. For this reason OTLP also allows a text-based encoding called JSON when the HTTP transport is used. It is larger and slower, but easy to inspect, which is handy for learning, testing, and browser applications. In production, the binary form is generally preferred for its speed and size.
Use the binary encoding for production traffic and the text encoding only when you need to read the messages with your own eyes. Both carry exactly the same information.
5How OTLP Organizes Data: Resource, Scope, and Items
OTLP groups telemetry in layers so shared information is written down only once.
If you simply sent a long list of individual spans or metric points, you would repeat the same information over and over. Every span from the same service would carry the same service name, the same version, and the same host details. OTLP avoids this waste with a neat three-level nesting that applies to every signal.
flowchart TD
R["Resource: the producer, such as service name and host"] --> S1["Scope: instrumentation library A"]
R --> S2["Scope: instrumentation library B"]
S1 --> I1["Spans, metric points, or log records"]
S1 --> I2["More spans, metric points, or log records"]
S2 --> I3["Spans, metric points, or log records"]
| Level | What it describes | Example |
|---|---|---|
| Resource | The entity that produced the telemetry | Service name, version, environment, host, container |
| Instrumentation scope | The library or component that created the items | The name and version of the web framework instrumentation |
| Items | The individual spans, metric data points, or log records | One request span, one counter value, one error log |
Why This Nesting Matters
Information about the producer is written once at the top and applies to everything beneath it. A batch containing a thousand spans from one service carries the service name once instead of a thousand times. This keeps messages small and fast, and it also makes the meaning clear: the resource attributes belong to the producer as a whole, while attributes on individual items belong to those items.
Think of a courier delivering a crate of parcels. The sender’s company details appear once on the crate’s cover sheet, not on every parcel inside. Within the crate, parcels are sorted into bags by department. Resource is the cover sheet, scope is the bag, and items are the parcels.
Because of this grouping, a single OTLP request can safely carry telemetry from several producers or libraries at once. A Collector forwarding data for many services often sends batches that contain many resources.
6The Signals OTLP Carries
One protocol, one overall approach, three main kinds of data.
OTLP carries each signal using the same overall design, with a dedicated service for each. This keeps things consistent: once you understand how one signal travels, the others look familiar. It also means a backend can choose to support traces first and metrics later, since each signal has its own entry point.
Traces
Batches of spans, each with identifiers, timing, attributes, events, links, and a status. Stable and widely supported.
Metrics
Named measurements with units and data points, in several shapes such as sums, gauges, and histograms. Stable and widely supported.
Logs
Records with timestamps, severity, a body, attributes, and optional trace identifiers. Stable and widely supported.
Profiles
Detailed snapshots of where a program spends CPU time and memory. A newer signal still under development.
Metric Shapes in OTLP
Metrics deserve a closer look because OTLP represents several different kinds of measurements, each shaped to suit how it is combined.
| Metric shape | What it holds | Everyday example |
|---|---|---|
| Sum | A running total, or a value that adds up | Total orders placed |
| Gauge | A single latest reading | Current temperature |
| Histogram | Counts of values falling into ranges | How long requests took |
| Exponential histogram | A compact histogram whose ranges scale automatically | Latencies spanning microseconds to seconds |
| Summary | Pre-computed percentiles, mainly for compatibility with older systems | Data imported from older sources |
OTLP metrics also state their temporality, which says whether each reported value is a running total since the start or only the change since the last report. Backends that expect one style can be fed the other with conversion, so it is useful to know which your backend prefers.
Attributes in OTLP can hold text, true-or-false values, whole numbers, decimals, and lists or collections of those, the same value types you meet everywhere else in OpenTelemetry.
7The Two Transports: OTLP over gRPC and OTLP over HTTP
The same data can travel by two different roads, each with its own strengths.
The transport is the way the encoded bytes cross the network. OTLP defines two. The first uses gRPC, a modern framework for programs to call functions on each other efficiently over a network. The second uses plain HTTP, the same technology that web browsers use. Both carry the same data structure, so choosing between them is about your environment, not about the information.
| Aspect | OTLP over gRPC | OTLP over HTTP |
|---|---|---|
| Conventional port | 4317 | 4318 |
| Built on | gRPC, which runs over HTTP version 2 | Ordinary HTTP requests |
| Encoding | Binary protobuf | Binary protobuf, or JSON as a text alternative |
| Strengths | Efficient, long-lived connections, widely used between Collectors | Passes easily through proxies, firewalls, and load balancers; works from browsers |
| Challenges | Needs infrastructure that supports HTTP version 2 and balances long-lived connections well | Slightly more overhead per request |
| Best fit | Server-side applications and Collector-to-Collector links | Restricted networks, browser and mobile apps, simple environments |
Imagine a shop with two doors leading to the same counter. One is a fast lane with a card reader for regular customers. The other is the ordinary front entrance that anyone can walk through. Both doors deliver people to the same counter, and the shopkeeper treats them identically once inside.
Which Should You Choose?
If your applications run on servers in a network you control, gRPC is a fine default, and it is very commonly used between Collectors. If a firewall or proxy gets in the way, or you need to send from browsers or from restricted environments, HTTP is usually the easier choice. Many teams use gRPC inside the data center and HTTP at the edges. The key point is that the sender and receiver must agree: a sender using gRPC cannot talk to a receiver port that expects HTTP.
Pointing a gRPC sender at the HTTP port, or the reverse. Everything looks configured, yet no data arrives. Check that the protocol setting and the port match.
8A Closer Look at OTLP over HTTP
The HTTP transport has a few details worth knowing, especially paths and encodings.
With the HTTP transport, the sender makes ordinary web requests carrying the telemetry in the body. The receiver listens on a set of fixed paths, one for each signal. The path tells the receiver which kind of data is arriving, so traces, metrics, and logs each go to their own address.
| Signal | Standard path | Content carried |
|---|---|---|
| Traces | /v1/traces | A batch of spans grouped by resource and scope |
| Metrics | /v1/metrics | A batch of metrics grouped by resource and scope |
| Logs | /v1/logs | A batch of log records grouped by resource and scope |
Two Encodings on HTTP
The body of an HTTP request can be binary protobuf or JSON, and the sender announces which using a standard content type header. The receiver replies in the same encoding. Binary is smaller and faster. JSON is readable and convenient for browsers and for quick manual tests with common tools.
JSON Details That Surprise People
OTLP’s JSON form follows the standard mapping of protobuf to JSON with a few special rules. Field names are written in lower camel case. Trace and span identifiers are written as hexadecimal text, not in the base64 text that protobuf’s default JSON mapping would use, which is a frequent source of confusion when people compare OTLP JSON with other protobuf JSON. Enumerated values such as severity or span kind are written as numbers. These rules are part of the OTLP specification, so any compliant tool will follow them.
The two encodings are like sending a message in shorthand code or in full sentences. The shorthand is quick and compact, the sentences are easy for anyone to read. Both say the same thing, and the recipient knows which is which from the label on the envelope.
Base Address versus Signal Address
A convenient feature of the HTTP transport is that you can configure a single base address, and the sender automatically adds the standard path for each signal. If you instead set an address for one specific signal, it is used exactly as written, with no path added. Mixing these up is a common reason for requests landing on the wrong address and failing with a not-found response.
If HTTP requests are failing with a not-found error, check whether the address already includes the signal path and whether your sender also adds it, creating a doubled or missing path.
9Requests and Responses: One Export at a Time
OTLP delivery is a simple conversation: the sender exports a batch and the receiver answers.
At the heart of OTLP is a simple pattern. The sender gathers a batch of telemetry and makes an export request. The receiver processes it and sends back a response saying how it went. Each signal has its own export operation, but they all follow the same pattern. Importantly, the response is not just a yes or no: it can describe partial success, which is a thoughtful feature for real-world conditions.
sequenceDiagram
participant S as Sender
participant R as Receiver
S->>S: Collect a batch of telemetry
S->>R: Export request with the batch
R->>R: Validate and accept the data
R-->>S: Response: success
S->>S: Remove the batch from its buffer
Three Possible Outcomes
Full Success
The receiver accepted everything. The sender can safely discard the batch it was holding.
Partial Success
The receiver accepted most of the data but rejected some items. It reports how many were rejected and why. The sender must not resend the whole batch.
Failure
The receiver could not accept the batch. The response says whether trying again might help.
Why Partial Success Matters
Imagine a batch of a thousand spans where five are malformed. Rejecting the whole batch would throw away nine hundred ninety-five good spans, and retrying would fail again for the same five. By accepting the good ones and reporting the rejected count, the receiver preserves useful data and tells the sender exactly what happened. The sender should log the rejection, but not resend the batch, because the problem lies in specific items, not in the delivery.
A mailroom accepts a box of fifty letters and finds that three have no address. A sensible clerk delivers the forty-seven good ones and sends a note saying three could not be delivered and why. Throwing away the whole box, or returning it for the sender to repack all fifty, would help nobody.
Senders typically send requests in batches and may keep several requests in flight at once, which keeps throughput high even when the network has some delay.
10Reliability: Retries, Backoff, and Throttling
Networks fail; OTLP says exactly how senders and receivers should behave when they do.
No network is perfectly reliable. Connections drop, servers restart, and receivers become overloaded. A good protocol must say what to do in these situations, otherwise every sender improvises and the result is chaos. OTLP defines clear behavior, which keeps temporary trouble from becoming data loss or a flood of repeated requests.
Retryable and Non-Retryable Failures
The first idea is that not all failures are equal. A temporary problem, such as a receiver being briefly unavailable or too busy, is worth retrying, because it will probably clear up. A permanent problem, such as a request that is malformed and can never be understood, should not be retried, because it would fail every time. OTLP specifies which response codes fall into each group for both transports.
| Situation | gRPC example | HTTP example | Retry? |
|---|---|---|---|
| Receiver temporarily unavailable | Unavailable status | Service unavailable or gateway errors | Yes, with delay |
| Receiver overloaded | Resource exhausted, when the receiver says when to retry | Too many requests | Yes, after waiting as told |
| Request took too long | Deadline exceeded | Gateway timeout | Yes, with delay |
| Malformed or invalid request | Invalid argument | Bad request | No |
| Permission problem | Unauthenticated or permission denied | Unauthorized or forbidden | No, until configuration is fixed |
Exponential Backoff with Jitter
When retrying, a sender must not hammer the receiver. The recommended approach is exponential backoff: wait a short time before the first retry, then roughly double the wait before each further attempt, up to a maximum. A little randomness, called jitter, is added so that thousands of senders who failed at the same moment do not all retry at the same instant and cause a second wave of overload.
First Attempt Fails
The sender receives a retryable failure, such as a temporary unavailable response.
Wait a Short Random Time
The sender waits briefly, with a little randomness added, then tries again.
Wait Longer Each Time
If failures continue, the waits grow, giving the receiver more time to recover.
Give Up Eventually
After a limit on time or attempts, the sender drops the batch rather than holding memory forever, and records that data was lost.
Receivers Can Ask Senders to Slow Down
A busy receiver is allowed to tell senders to back off, and on HTTP it can state how long to wait before retrying. This shared signal lets the whole system slow down gracefully rather than collapse. Senders that honor it help the receiver recover quickly.
If a busy restaurant tells guests to come back in twenty minutes, sensible guests do. Guests who keep knocking on the door every few seconds only make things worse. Backoff and jitter are the manners of a well-behaved telemetry sender.
Retrying forever or retrying non-retryable errors. This wastes memory and bandwidth, and can mask a real configuration problem such as bad credentials.
11Batching, Compression, and Efficiency
Telemetry volume can be huge, so OTLP is built to move it efficiently.
A busy system can produce millions of spans, metric points, and log records every minute. Sending each one in its own network request would be enormously wasteful. For that reason, senders group items into batches and send them together. Batching reduces the number of network connections, spreads fixed costs over many items, and makes better use of bandwidth.
Batching
Items are buffered and sent together, either when the batch is full or after a short delay, whichever comes first.
Binary Encoding
Protobuf is compact, so the same data takes fewer bytes than text formats.
Compression
Optional compression, with gzip being the commonly supported choice, shrinks batches further at the cost of some processing time.
Shared Resource Information
The resource and scope nesting writes common details once per group instead of once per item.
Concurrent Requests
Senders can have several export requests in flight at once, keeping the connection busy.
Choosing Batch Sizes
Batch size involves a trade-off. Large batches are efficient but use more memory and delay delivery, and receivers may enforce limits on message size, rejecting anything larger. Small batches arrive sooner but carry more overhead. Most libraries offer sensible defaults and settings for the maximum batch size and the maximum waiting time. Unless you have a specific problem, the defaults are a good starting point.
A delivery van that leaves with one parcel at a time wastes fuel. A van that waits all day to fill up delivers everything late. A good dispatcher sends the van when it is reasonably full or when a set time has passed, whichever happens first.
Compression Trade-offs
Compression shrinks the data sent over the network, which saves bandwidth and can reduce costs when data crosses paid network links. The price is some extra processor time on both ends. For traffic inside a fast local network, the saving may not be worth it. For traffic across the internet or between regions, compression is usually a clear win.
Turn on compression for links that cross expensive or slow networks, and test whether it helps on fast local links before enabling it everywhere.
12Securing OTLP Connections
Telemetry often contains sensitive details, so the road it travels must be protected.
Telemetry can reveal a lot about your systems: internal service names, user identifiers, request details, and sometimes fragments of sensitive data inside messages. Anyone who can read or forge OTLP traffic can learn about your system or pollute your monitoring. OTLP itself leaves security to well-established mechanisms on the transport, which are widely understood and well tested.
Encryption in Transit
Transport Layer Security encrypts the connection so nobody on the network can read the data.
Server Identity
The sender checks the receiver’s certificate, so data is not sent to an impostor.
Mutual Authentication
With mutual TLS, the receiver also checks the sender’s certificate, so only approved senders can deliver data.
Credentials in Headers
Senders can attach tokens or keys as headers, which backends commonly require to identify the account receiving the data.
Network Controls
Firewalls and network policies limit who can even reach the receiver.
Local Convenience versus Real Safety
During development, it is common to run a Collector on your own machine and send data to it without encryption, because nothing leaves the machine. That is fine for local work. In production, any connection that crosses a network should be encrypted, and receivers that face wider networks should require authentication. Remember also that receiving a connection on every network address makes the receiver reachable by anyone who can route to it, so choose listening addresses deliberately.
Sending unencrypted telemetry over a shared network is like sending postcards: anyone along the way can read them. Encryption is the sealed envelope. Authentication is the signature that proves who sent the letter and who is allowed to receive it.
Keep access tokens and keys out of shared files and logs. Supply them through secure configuration, and rotate them if they are ever exposed.
13Configuring OTLP in Applications
Most OTLP behavior is controlled by a handful of standard settings, which are the same across languages.
One of the nicest things about OTLP is that every OpenTelemetry library uses the same standard names for its main settings, usually through environment variables. This means that a team running services in several languages can configure them all in the same way, and operators can change a destination without touching application code.
| Setting | What it controls | Notes |
|---|---|---|
| Endpoint | Where to send the data | Defaults to the local machine on the conventional port for the chosen transport |
| Protocol | Which transport and encoding to use | Options include gRPC, HTTP with binary encoding, and HTTP with JSON; the default varies by language |
| Headers | Extra headers sent with each request | Commonly used for access tokens or keys |
| Compression | Whether and how to compress | Gzip is the common choice |
| Timeout | How long to wait for a response | Prevents requests from hanging forever |
| Certificate settings | Which certificates to trust or present | Used for encrypted and mutually authenticated connections |
General Settings and Per-Signal Settings
Each setting normally exists in two forms: a general one that applies to all signals, and signal-specific ones that override it for traces, metrics, or logs individually. This lets you send traces to one destination and metrics to another if you need to. When you set only the general one, everything goes to the same place, which is the common case.
The Default Destination
If you configure nothing, libraries generally try to send to the local machine on the conventional port. This matches a very common pattern: a Collector running on the same host or in the same pod as the application. It also explains the classic first-day puzzle where an application runs fine but no data appears anywhere, because no Collector is listening on the default address.
Setting the endpoint is like writing the address on a parcel. The general setting is the default delivery address for all your mail. The per-signal settings are special instructions for particular parcels, such as sending the fragile items to a different warehouse.
Prefer configuring OTLP through environment variables rather than code. Operators can then change destinations, credentials, and protocols without a new release of the application.
14OTLP and the Collector
The Collector uses OTLP on both its input and its output, which makes it the natural hub.
The OpenTelemetry Collector is a standalone program that receives telemetry, processes it, and sends it onward. OTLP is its native language. The Collector includes an OTLP receiver to accept incoming data and OTLP exporters to forward data to other Collectors or to backends that accept OTLP. Because both ends use the same protocol, Collectors chain together smoothly.
flowchart LR
A1["Service A"] -->|"OTLP"| AG["Agent Collector"]
A2["Service B"] -->|"OTLP"| AG
AG -->|"OTLP"| GW["Gateway Collector"]
GW -->|"OTLP"| B1["Backend 1"]
GW -->|"Other protocol"| B2["Backend 2"]
Why OTLP Between Collectors Is Such a Good Fit
When one Collector forwards data to another, OTLP carries everything faithfully, including resources, scopes, attributes, identifiers, and partial-success information. Nothing is lost in translation, because both sides use the same data model. That is why OTLP is the recommended way to link Collectors into agents and gateways.
Translating at the Edges
Not every system speaks OTLP. Some applications still emit older trace formats or expose metrics for scraping, and some backends accept only their own formats. The Collector acts as a translator at the edges: its receivers convert older formats into its internal data, and its exporters convert that data into whatever the destination wants. OTLP sits comfortably in the middle as the native form, which is why many organizations standardize on OTLP internally and translate only at the boundary.
| Collector part | OTLP role |
|---|---|
| OTLP receiver | Accepts OTLP over gRPC, HTTP, or both |
| OTLP exporter over gRPC | Sends data onward in OTLP using gRPC |
| OTLP exporter over HTTP | Sends data onward in OTLP using HTTP |
| Processors in between | Work on the internal form, not on any specific wire format |
The Collector’s internal data model matches OTLP closely, so OTLP in and OTLP out is the lowest-loss path through it.
15OTLP Compared with Other Protocols
Understanding the older alternatives shows why OTLP was created.
Before OTLP, telemetry systems used a variety of formats and styles. Some were designed for a single signal, some were tied to a single vendor, and some used a pull model where the monitoring system fetches data rather than the application sending it. Seeing these differences clarifies what OTLP improves.
| Protocol or style | Typical signal | Style | Limitation compared with OTLP |
|---|---|---|---|
| Older tracing formats such as Jaeger and Zipkin | Traces only | Push | No metrics or logs; each system has its own format |
| Prometheus exposition | Metrics only | Pull | Metrics only, and the model differs in places from OpenTelemetry’s |
| StatsD | Simple metrics | Push | Limited metric types and little structure |
| Syslog and plain log files | Logs | Push or file reading | Weak structure; correlation with traces is difficult |
| Vendor-specific formats | Varies | Varies | Tie you to one vendor |
| OTLP | Traces, metrics, logs, and more | Push | Requires receivers that understand it, which is now common |
The Unifying Advantage
The biggest advantage of OTLP is that one protocol carries all the signals using one data model, with shared resource and attribute concepts. That makes correlation natural: the same resource describes a service in its traces, metrics, and logs, and trace identifiers travel inside log records. With separate protocols, joining signals together requires extra effort and guesswork.
Moving to OTLP Gradually
You do not need to switch everything overnight. A practical path is to put a Collector in the middle, let existing systems keep sending in their current formats, and have the Collector convert them. Then move new applications to OTLP directly, and migrate older ones over time. During the transition, the Collector can send to old and new backends at once, so you can compare results before removing the old path.
Moving to a standard shipping container does not require rebuilding every warehouse on the same day. Ports installed equipment that could handle both old crates and new containers, and shippers gradually switched. A Collector plays the role of that dual-capable port.
Standardize on OTLP inside your organization, and translate to other formats only at the boundary where a particular tool demands it.
16Troubleshooting OTLP Delivery
A short routine finds most delivery problems.
When telemetry does not arrive, the cause is usually simple: a mismatched setting or a blocked connection. Working from the sender toward the receiver in a fixed order saves time and avoids guesswork.
Check the Endpoint
Is the address correct and reachable? For HTTP, does it include or omit the signal path the way your sender expects?
Match Protocol and Port
Does the sender’s protocol, gRPC or HTTP, match what the receiver listens for on that port?
Check Encryption Settings
If one side expects encryption and the other does not, the connection fails. Check certificates, trust settings, and whether an insecure local mode is intended.
Check Credentials
Backends often reject requests with missing or wrong tokens. Look for authentication or permission errors, which should not be retried.
Look at the Network Path
Firewalls, proxies, and load balancers may block the port, lack support for the transport, or enforce size limits.
Read Both Sides’ Logs
Sender libraries usually log export failures, and Collectors log receiving problems. A temporary debug output that prints what the Collector received confirms whether data arrives at all.
Common Symptoms
Nothing Arrives, No Errors
Often a default local endpoint with no listener, or a pipeline that does not include the receiver.
Connection Errors
Usually a protocol or port mismatch, a blocked port, or encryption disagreement.
Not Found on HTTP
Typically a wrong or doubled signal path in the address.
Message Too Large
A batch exceeds the receiver’s size limit. Reduce batch size or raise the limit deliberately.
Debugging the data model when the real problem is the connection. Confirm that the receiver sees any traffic at all before examining what is in the messages.
17Real-World Examples
Seeing OTLP in familiar situations makes the ideas concrete.
Switching Monitoring Vendors Without Touching Applications
A company sends all telemetry through a Collector over OTLP. When they decide to change monitoring products, they update the Collector’s destination and credentials. The applications, dozens of them in several languages, need no changes and no redeployment.
Running Two Backends During an Evaluation
A team wants to compare a new tool with the current one. The Collector exports the same OTLP data to both destinations at once. After a month of side-by-side comparison, they choose confidently and retire the old path.
Telemetry from Web Browsers
A company collects performance data from real users’ browsers. Browser code sends OTLP over HTTP to a public-facing Collector, which requires authentication and enforces size limits, and then forwards the data internally over OTLP using gRPC.
Agents and a Gateway in a Large Platform
Each host runs a small agent Collector that receives OTLP from nearby applications and forwards it to a central gateway Collector. The gateway applies sampling and redaction, then exports to the backend. OTLP is the common language at every hop.
Bridging Legacy Systems
An older application exposes metrics in a scraping format and emits traces in an older tracing format. The Collector’s receivers convert both into its internal data and re-export them as OTLP, giving the legacy system modern, unified telemetry without changes to its code.
Surviving a Backend Outage
The backend becomes unavailable for several minutes. Collectors receive retryable failures and retry with backoff, while senders buffer data within their limits. When the backend returns, the buffered data is delivered, and only the oldest overflow, beyond configured limits, is lost.
18Advantages and Trade-offs
OTLP is a strong default choice, but it is helpful to know its limits.
Advantages
- One protocol and data model for traces, metrics, logs, and more.
- Vendor-neutral, so you can change or add backends without re-instrumenting.
- Efficient binary encoding with optional compression and batching.
- Clear, shared rules for retries, partial success, and throttling.
- Two transports to suit different networks, with identical data.
- Natural fit with the Collector, and broad support among backends.
Disadvantages / Trade-offs
- The gRPC transport needs infrastructure that supports HTTP version 2 and handles long-lived connections well.
- Binary data is hard for humans to read without tools.
- Not every backend or older system accepts OTLP natively, so translation may be needed.
- Mismatched protocol, port, or path settings cause silent-looking failures.
- Senders buffer data in memory, so long outages can still lose data.
Who Benefits from a Shared Protocol?
A shared protocol helps many different people. Application developers instrument once and never worry about which monitoring tool the company uses next year. Platform and operations teams control destinations, credentials, and processing in one central place. Security teams have a single, well-understood path to protect and inspect. Finance and management gain negotiating power, because switching vendors no longer requires rewriting code across dozens of services. Even tool vendors benefit, since supporting one protocol gives them access to every OpenTelemetry user at once.
Is OTLP the Right Choice?
For nearly every new project, yes. It is the default of the OpenTelemetry ecosystem, it is broadly supported, and it protects you from lock-in. The main reason to use something else is a specific tool that accepts only its own format, and even then the Collector can translate. A sensible rule is to use OTLP everywhere you control both ends of the connection, and translate at the edges only where you must.
Keeping Up with Change
The protocol is designed to evolve without breaking existing users. New fields are added in ways that older senders and receivers simply ignore, and the stable signals follow compatibility promises. Even so, it is wise to read release notes when upgrading libraries or Collectors, and to test changes in a non-production environment first, especially for newer signals that are still maturing.
A Simple Adoption Path
Start by running a Collector with an OTLP receiver. Point a single service at it using the standard environment settings. Confirm that data arrives, then add an exporter to your chosen backend. Next, enable encryption and authentication where data crosses networks. Add compression for expensive links, and review retry and batch settings. Then roll the same pattern out to the other services, and finally retire any older direct connections. Each step delivers value on its own.
If you are choosing between gRPC and HTTP and have no strong constraint, start with the one that your network and tools handle most easily. You can change later by editing one setting.
19Best Practices and Common Mistakes
A handful of habits prevent most problems.
Habits Worth Building
Send to a Collector
Send application data to a nearby Collector rather than straight to the backend, so you can change destinations and processing centrally.
Use Standard Settings
Configure endpoints, protocols, and headers through the standard environment settings so every language behaves alike.
Match Protocol and Port
Double-check that the transport and port agree on both sides before debugging anything else.
Encrypt and Authenticate
Use TLS on every connection that crosses a network, and require credentials on receivers that face wider networks.
Respect Retry Rules
Retry only retryable failures, with backoff and jitter, and never forever.
Watch for Rejections
Log and monitor partial-success rejections and dropped data so silent loss does not go unnoticed.
Mistakes to Avoid
Problem
A sender is configured for one transport while the receiver listens for the other, or the HTTP address and the sender’s automatic path handling disagree.
Why It’s Harmful
No data arrives, errors are vague, and teams lose hours debugging the data when the problem is the connection.
Correct Approach
Document the protocol and port for each receiver, use the conventional ports, and test a connection end to end before relying on it.
Problem
Telemetry travels unencrypted over shared or public networks, receivers listen on every address without authentication, and tokens are stored in shared files.
Why It’s Harmful
Anyone on the path can read sensitive details or inject fake data, and leaked tokens give outsiders access to your monitoring account.
Correct Approach
Encrypt connections, authenticate senders where receivers are exposed, restrict listening addresses, and supply credentials through secure configuration that can be rotated.
Problem
Senders retry every failure immediately and forever, or oversized batches are sent repeatedly to a receiver that always rejects them.
Why It’s Harmful
Retry storms overload recovering receivers, memory fills with undeliverable data, and permanent errors such as bad credentials or oversized messages are never fixed.
Correct Approach
Retry only retryable failures with exponential backoff and jitter, set limits, and treat permanent errors as configuration problems to be fixed rather than retried.
Resending an entire batch after a partial-success response. The receiver already accepted most of the data, so resending creates duplicates. Log the rejected count and move on.
20Frequently Asked Questions
Quick answers to the questions beginners ask most often.
OpenTelemetry Protocol. It is the standard way OpenTelemetry components encode, transport, and deliver traces, metrics, and logs.
Traces, metrics, and logs are stable. Support for profiles is being added as a newer signal.
They carry the same data. gRPC is efficient and common between Collectors, using the conventional port 4317. HTTP passes more easily through proxies and firewalls and works from browsers, using the conventional port 4318.
Mainly binary, using Protocol Buffers for compact and fast transfer. A JSON text encoding is also available over HTTP for readability and browser use.
Push. The sender delivers batches to the receiver, unlike scraping systems where the monitoring tool fetches data from the application.
Senders receive retryable failures and retry with exponential backoff and jitter while buffering data within limits. After the limit, the oldest data is dropped. Non-retryable errors are not retried.
A response saying the receiver accepted most of a batch but rejected some items, with a count and a reason. The sender should record the rejection and should not resend the whole batch.
No. Applications can send OTLP straight to any backend that accepts it. But a Collector in between gives you flexibility to change destinations, process data, and apply security and sampling centrally.
Yes, via the Collector. Its receivers convert older formats into its internal data, which it can then export as OTLP.
Use the standard environment settings for the endpoint, protocol, headers, and compression. They work the same way across OpenTelemetry libraries in different languages, and signal-specific versions can override the general ones.
21Summary and Key Takeaways
OTLP, the OpenTelemetry Protocol, is the standard shipping container for telemetry. It defines how traces, metrics, and logs are encoded using Protocol Buffers, how they travel over either gRPC or HTTP, and how delivery is acknowledged, retried, and throttled. Data is organized by resource, scope, and individual items so shared details are written once. Senders push batches, receivers reply with success, partial success, or failure, and clear rules govern retries, backoff, and security. OTLP is the native language of the Collector, which chains agents and gateways together and translates older formats at the edges. Use OTLP wherever you control both ends, secure every network hop, keep settings consistent through the standard configuration, and you gain freedom to change tools without ever re-instrumenting your applications.
Key Takeaways
- One standard for delivery — OTLP defines encoding, transport, and delivery behavior for traces, metrics, and logs, with profiles emerging.
- Protocol Buffers underneath — a compact, fast, schema-based binary encoding, with an optional JSON form over HTTP for readability.
- Two transports, same data — gRPC on the conventional port 4317 and HTTP on 4318; both must match on sender and receiver.
- Resource, scope, and items — nesting writes shared producer details once, keeping messages small and meaning clear.
- Reliable by design — success, partial success, and failure responses plus retry with backoff and jitter keep temporary trouble from becoming data loss.
- Secure the road — use TLS, authenticate where receivers are exposed, and keep credentials out of shared files.
- The Collector is the hub — OTLP in and out chains Collectors losslessly, while translation to other formats happens only at the edges.