What Is an Exporter in OpenTelemetry?
An exporter is the part of OpenTelemetry that carries your traces, metrics and logs out of your application and delivers them to the place where people can actually look at them. This guide explains it from zero, with analogies, diagrams and real-world patterns.
Imagine a busy restaurant kitchen. Cooks are chopping, frying and plating all night long. Every action happens inside the kitchen, behind a wall, where the owner cannot see it. If the owner wants to know how many orders were late, which dish takes the longest, or why a table waited forty minutes, someone has to write those facts down and carry the notes out of the kitchen to the office. That someone is a delivery person who collects the notes, bundles them neatly, and walks them to the right desk. In the world of software observability, that delivery person has a name: the exporter.
1Why Telemetry Needs a Way Out
Data that stays trapped inside an application is just as useless as data that was never collected.
Modern applications are rarely a single program on a single machine. A shopping website might be made of dozens of small services, each running in many copies, spread over many computers. When something goes wrong, nobody can walk up to one machine and read its screen. Engineers need the applications to report on themselves. This self-reporting information is called telemetry, a word that simply means measuring something from a distance and sending the result somewhere else.
Telemetry is useful only when it arrives somewhere. A log line written in a private memory buffer of a service that crashed a second later is gone forever. A measurement of response time that never leaves the process cannot be charted. So every observability system must answer two questions: how do we collect information, and how do we move it out? OpenTelemetry answers the first question with its instrumentation and the second question with exporters.
Think of a weather station on a mountain. The thermometer measures the temperature, but a thermometer alone helps nobody in the valley. The radio transmitter attached to the station sends the reading down to the forecasting office. The thermometer is instrumentation. The radio transmitter is the exporter.
What goes wrong without a clear way out
Before standards existed, every monitoring product shipped its own agent and its own way of sending data. If a company wanted to change vendors, engineers had to rewrite instrumentation across hundreds of services. Exporters solve this problem by separating two jobs: producing telemetry and delivering telemetry. The code that creates telemetry stays the same, and only the delivery part is swapped when the destination changes.
2A Quick Look at OpenTelemetry Itself
To understand one part, we first need a rough map of the whole machine.
OpenTelemetry, often shortened to OTel, is an open-source project that defines how to create, process and move telemetry data. It is vendor neutral, which means it does not belong to any single monitoring company. It provides a specification (the rules), a set of language libraries called SDKs, an optional standalone program called the Collector, and a data format called OTLP, which stands for OpenTelemetry Protocol.
The three signals
OpenTelemetry talks about three kinds of data, each called a signal. Understanding them is important because exporters exist for each one.
Traces
A trace follows one request as it travels through many services. It is made of spans, where each span is one step, such as a database call, with a start time and a duration.
Metrics
Metrics are numbers measured over time, such as requests per second, memory used, or queue length. They are cheap to store and great for dashboards and alerts.
Logs
Logs are text records of events, such as an error message. OpenTelemetry can link a log to the trace that produced it so engineers can jump between them.
Resource
A resource describes who is sending the data, for example the service name, version and host. Exporters carry this label along with every batch of data.
The building blocks
Inside an application, the OpenTelemetry SDK has a few cooperating pieces. A provider is the factory that hands out tracers, meters and loggers. A processor or reader receives finished data and decides when to send it. An exporter takes the data from the processor and performs the actual delivery. Keeping these jobs separate makes each piece small, replaceable and testable.
If the words feel heavy, remember a simple chain: something creates data, something decides when to ship it, and something ships it. The last link in that chain is the exporter.
3So, What Exactly Is an Exporter?
An exporter is a pluggable component that takes finished telemetry and sends it to a destination.
Let us define it carefully. An exporter in OpenTelemetry is a component that receives batches of telemetry data from the SDK or from the Collector and is responsible for converting that data into a specific format and transmitting it to a specific destination. That destination may be a monitoring backend, a database, another OpenTelemetry Collector, a file, or even a simple console window.
The word pluggable matters. The rest of your application does not know or care which exporter is in use. It only knows that when it creates a span or records a measurement, the data will eventually leave. You can swap the exporter for another one by changing configuration, and the instrumentation code stays untouched. This is the heart of vendor neutrality.
An exporter is like a courier company that you can change at any time. The parcel, which is your telemetry, stays the same. The courier decides the truck, the route and the delivery address format. Choose a different courier and the same parcel arrives at a different warehouse.
The small list of duties
According to the OpenTelemetry specification, an exporter has a very small and focused contract. It must be able to accept a batch of data and send it, it must be able to flush anything still waiting when asked, and it must be able to shut down cleanly, releasing connections and other resources. Everything else, such as how to choose a batch size or when to retry, is either the job of the processor in front of it or an optional extra built around it.
Export
Receive a batch of spans, metric points or log records and deliver them to the destination.
Force flush
Push out whatever is still waiting right now, which is useful just before a short-lived program ends.
Shutdown
Finish pending work, close network connections and release resources so nothing leaks.
Many beginners think an exporter collects data. It does not. Collecting is the job of instrumentation and receivers. An exporter only sends data that has already been collected.
4Where the Exporter Sits in the Pipeline
Position tells you responsibility: the exporter is the last step before data leaves the building.
Follow a single span from birth to destination. Your code starts a span when a request arrives. The span ends when the work finishes. At that moment the SDK hands the finished span to a span processor. The processor decides whether to send it immediately or wait and group it with others. When the time is right, the processor gives the group to the exporter. The exporter packages it, sends it over the network, and the backend stores it.
flowchart LR
A["Your Application Code"] --> B["OpenTelemetry API"]
B --> C["SDK Provider"]
C --> D["Processor or Reader"]
D --> E["Exporter"]
E --> F["Backend or Collector"]
The API and SDK split
OpenTelemetry deliberately splits its libraries into an API and an SDK. The API is the thin set of calls that application and library authors use to create telemetry. The SDK is the real engine that processes and exports it. If no SDK is installed, the API does nothing and costs almost nothing. Exporters live in the SDK side, which is why library authors never need to choose one. Only the person who builds the final application decides where data goes.
Because exporters belong to the application owner and not to library authors, a shared open-source library can be instrumented once and still work with every company’s choice of monitoring product.
5Exporter vs Processor vs Receiver vs Collector
These four words are often mixed up, so let us place each one clearly.
Beginners usually stumble on vocabulary. Four terms appear again and again: exporter, processor, receiver and Collector. Each has a distinct job. The table below compares them side by side, and the analogy that follows ties them together.
| Term | Main job | Where it lives | Everyday comparison |
|---|---|---|---|
| Receiver | Accepts incoming telemetry from outside sources | Collector | The front door of a post office |
| Processor | Changes, filters, groups or enriches data on the way through | SDK and Collector | The sorting room that stamps and bundles parcels |
| Exporter | Sends data out to a destination | SDK and Collector | The delivery truck leaving the depot |
| Collector | A standalone program that hosts receivers, processors and exporters | Its own process | The entire post office building |
A post office has a door where parcels come in, a back room where they are sorted and labeled, and trucks that take them away. The door is the receiver, the back room is the processor, and the trucks are exporters. The whole building, with its staff and rules, is the Collector.
Why the processor comes first
Inside the SDK, the span processor sits between your code and the exporter. The two commonly used styles are the simple one, which sends each span the moment it ends, and the batch one, which waits and sends groups. The simple style is easy to understand but slow for real systems, because it makes the network call for every single span. The batch style is the usual choice for production, which leads us to the inner workings of an exporter.
6One Exporter Family per Signal
Traces, metrics and logs each have their own exporter type because their data looks different.
It is tempting to imagine one universal exporter for everything. In practice there are three families, because the three signals behave differently. Spans are individual events that finish at unpredictable moments. Metrics are summaries that are naturally collected at regular intervals. Logs are streams of records. Each family therefore has its own interface, and a backend that supports all three usually offers all three exporters, often packaged together under one destination name.
Span Exporter
Receives finished spans in groups. Normally paired with a batch span processor that decides when each group is ready.
Metric Exporter
Receives a snapshot of all measurements at a regular interval. Paired with a reader that wakes up on a timer and collects current values.
Log Record Exporter
Receives log records in groups. Paired with a log record processor that mirrors the batch idea from traces.
How metrics differ
Metrics deserve special attention. Unlike spans, which are pushed out as they finish, metrics are usually read on a schedule. A component called a metric reader wakes up every so often, commonly about once a minute by default, gathers the current numbers, and passes them to the metric exporter. This is why a metric appears on a dashboard with a short delay, while a trace may appear within seconds.
Metric exporters also deal with a concept called temporality. A cumulative metric reports the total since the program started, like a car odometer. A delta metric reports only the change since the last report, like a trip meter. Some backends prefer one style and some prefer the other, so metric exporters let you choose which style to emit.
Because the three families are independent, you may send traces to one backend, metrics to another, and logs to a third. Mixing destinations is normal in real companies.
7How an Exporter Works Inside
Behind the simple promise of sending data are several careful steps that protect your application.
An exporter must do its work without hurting the application that produced the data. If sending telemetry made a website slower, nobody would use it. For this reason the pipeline around the exporter is built carefully. Let us walk through what happens for a batch of spans.
Spans wait in a queue
When a span ends, the batch processor places it in a memory queue. This is very fast, so the application thread continues immediately.
A background worker wakes up
A separate background thread checks the queue. It wakes up when enough time has passed or when enough spans have accumulated, whichever comes first.
The batch is handed to the exporter
The worker takes a group of spans, commonly up to a few hundred at a time, and calls the exporter with that group.
The exporter serializes the data
Serialization means turning in-memory objects into bytes that can travel. For the standard protocol this is a compact binary format, optionally compressed to save bandwidth.
The network call is made
The exporter opens or reuses a connection and sends the bytes to the destination, waiting up to a limited time for an answer.
Success or failure is reported
The destination replies with success or an error. The exporter reports the result back so the pipeline can decide whether to retry or drop the data.
sequenceDiagram
participant App as Application Thread
participant Q as Memory Queue
participant W as Background Worker
participant X as Exporter
participant B as Backend
App->>Q: Add finished span
Note over App: Application continues at once
W->>Q: Take a batch
W->>X: Export batch
X->>B: Send serialized data
B-->>X: Success or error
X-->>W: Result
Picture a mailbox at the end of your driveway. You drop letters in and walk back to the house without waiting. The mail carrier arrives later, empties the box, and takes everything in one trip. You never stand at the curb waiting for each letter to be delivered, and the carrier does not make a separate trip for each envelope.
Why batching matters so much
Making a network call has a fixed cost: opening connections, checking security, waiting for a reply. Sending one thousand spans in a single call pays this cost once, while sending them one by one pays it a thousand times. Batching therefore reduces network traffic, reduces central processing cost, and increases how much data the system can handle. The trade-off is a small delay, since data waits a moment before leaving.
8Protocols and Formats: OTLP and Friends
An exporter must speak the same language as the destination, and OTLP is the language OpenTelemetry prefers.
A protocol is an agreed set of rules for how two programs talk. OTLP, the OpenTelemetry Protocol, is the native protocol of the project. It describes how spans, metrics and logs are structured and sent. Because it is the project’s own standard, it carries all the fields without loss and it is understood by the Collector and by a rapidly growing list of backends.
OTLP over gRPC
Uses a fast, long-lived connection with streaming support. By convention it listens on port 4317. Popular for service-to-Collector traffic inside a data center.
OTLP over HTTP
Uses ordinary web requests, by convention on port 4318, and can carry data as binary protobuf or as JSON. Friendlier to firewalls, proxies and browsers.
Older Vendor Formats
Some systems still expect their own formats, such as Zipkin or Jaeger style data. Dedicated exporters translate OpenTelemetry data into those shapes.
Console and File
These exporters print to the screen or write to a file. They are perfect for learning and troubleshooting, but not for production scale.
Choosing between gRPC and HTTP
Both transports carry the same data, so the choice is about the environment. Inside a private network where services already use gRPC, that option is efficient and natural. When data must cross corporate firewalls, pass through load balancers that understand only web traffic, or originate from a web browser, the HTTP option is usually easier. Many teams pick HTTP for its simplicity and fewer surprises.
Pointing a gRPC exporter at the HTTP port, or the other way around, is one of the most frequent setup errors. The two ports speak different dialects, and the connection will fail or hang with confusing messages.
9Push Exporters and Pull Exporters
Some exporters send data out on their own, while others wait to be asked.
Most exporters are push exporters. They take the initiative: when a batch is ready, they send it to the destination. The destination does not have to know in advance where the application lives, which is convenient when applications start and stop constantly.
A smaller group are pull exporters. The best-known example is the Prometheus-style exporter. Instead of sending data, it opens a small web page on the application that lists the current metric values. A separate monitoring server, which already knows the address, visits that page on a schedule and reads the numbers. Here the destination takes the initiative.
flowchart TB
subgraph PUSH["Push model"]
A1["Application"] -->|"sends batches"| B1["OTLP Backend"]
end
subgraph PULL["Pull model"]
A2["Application exposes metrics page"]
B2["Scraping server"] -->|"visits on a schedule"| A2
end
Push is like a newspaper delivered to your doorstep every morning. Pull is like walking to the newsstand when you want to read. Both get you the news, but the effort sits on different shoulders.
Push Advantages
- Works well for short-lived programs that disappear quickly
- No need to open an inbound port on the application
- Data leaves immediately when ready
- Same model works for traces, metrics and logs
Push Trade-offs
- The application needs to know the destination address
- A slow or down destination can pile up data in memory
- Sending adds some network and CPU cost to the application
Pull Advantages
- The monitoring server controls how often it reads
- Easy to see if an application is alive, since a failed visit is a signal
- Fits well with existing scraping-based monitoring setups
Pull Trade-offs
- Needs an open inbound port and discoverable addresses
- Poor fit for short-lived jobs that finish between visits
- Mostly suited to metrics, not traces or logs
10SDK Exporters vs Collector Exporters
Exporters appear in two places, and the difference changes how you design your system.
So far we have mostly described exporters inside the application SDK. But the Collector, the standalone program mentioned earlier, has exporters too. They do the same job, which is sending data out, but they sit at a different point in the journey. An SDK exporter sends data from the application. A Collector exporter sends data onward from the Collector to its final home.
The Collector is built as a set of pipelines. A pipeline lists receivers that accept data, processors that transform it, and exporters that send it. One pipeline can have many exporters at once, so the same data can be copied to several destinations. This fan-out ability is one of the strongest reasons teams adopt the Collector.
flowchart LR
S1["Service A SDK"] -->|"OTLP"| R["Collector Receiver"]
S2["Service B SDK"] -->|"OTLP"| R
R --> P["Collector Processors"]
P --> E1["Exporter to Tracing Backend"]
P --> E2["Exporter to Metrics Store"]
P --> E3["Exporter to Log Archive"]
| Question | SDK exporter | Collector exporter |
|---|---|---|
| Where does it run? | Inside every application process | Inside the Collector process |
| What does it send? | Data created by that one application | Data gathered from many sources |
| Typical destination | A nearby Collector or a backend | One or more final backends |
| Who manages it? | Application developers | Platform or operations teams |
| Changing the destination | Reconfigure and restart each application | Change one Collector setting |
Applications use a simple OTLP exporter that points at a nearby Collector. The Collector then holds the vendor-specific exporters. When the company changes vendors, only the Collector is touched, and hundreds of applications remain unchanged.
11Choosing the Right Exporter
The best exporter depends on your goal, your environment and the shape of your system.
There is no single correct choice. The right exporter depends on where the data needs to end up, how large the system is, and how much operational effort your team can handle. The scenarios below show how different situations lead to different decisions.
Learning and local development
Use the console exporter. It prints telemetry straight to your screen, so you can see exactly what your application produces without setting up any backend. It is a perfect classroom tool.
A small application with one backend
Send OTLP directly from the SDK to the backend. Fewer moving parts means fewer things to break, and the data volume is low enough that direct sending is comfortable.
Many services in a company
Send OTLP from each service to a Collector, and let the Collector manage the final exporters. This gives central control over destinations, filtering and security.
An existing metrics setup based on scraping
Use the pull-style metrics exporter so your current monitoring server can keep reading numbers the way it always has, while tracing goes through OTLP.
Compliance and long-term archive
Add a Collector exporter that writes copies of the data to durable storage, while another exporter sends the same data to a live analysis tool.
flowchart TD
Q1{"Just learning or debugging?"}
Q1 -->|"Yes"| A["Console exporter"]
Q1 -->|"No"| Q2{"Many services or many destinations?"}
Q2 -->|"Yes"| B["OTLP to a Collector, then backend exporters"]
Q2 -->|"No"| Q3{"Existing scraping setup for metrics?"}
Q3 -->|"Yes"| C["Pull metrics exporter plus OTLP for traces"]
Q3 -->|"No"| D["OTLP directly to the backend"]
12Reliability: Queues, Retries and Back-pressure
Networks fail, backends slow down, and a good exporter plans for bad days.
On a perfect day, every batch is sent and acknowledged within milliseconds. Real systems are not perfect. The backend may be restarting, a network cable may be unplugged, or a sudden traffic spike may flood the pipeline. A good exporter setup is designed around these facts. Three ideas keep the system healthy: queues, retries and dropping.
Queues absorb bursts
A queue is a waiting line. If data is produced faster than it can be sent for a short time, the extra data waits in the queue instead of being lost. Queues have a maximum size, because memory is limited. A larger queue survives longer outages but uses more memory.
Retries handle short failures
Some failures are temporary, such as a brief network glitch. In those cases the exporter can try again after a short pause. A well-behaved exporter waits a little longer after each failed attempt, a pattern called exponential back-off. This prevents a thousand applications from hammering a struggling backend at the same moment. Only errors that are likely to be temporary should be retried. A rejection that says the data is malformed will fail forever, so retrying it is wasted effort.
Dropping protects the application
When the queue is full and the backend is still unreachable, the exporter has a hard choice. It can block the application until space appears, or it can discard the oldest or newest data. OpenTelemetry strongly favors protecting the application. Losing some telemetry is unfortunate, but freezing a customer-facing service because the monitoring system is down would be far worse.
Think of a water tank under a tap. A short burst of extra water fills the tank, and nothing is lost. If the drain stays blocked for too long, the tank overflows. A sensible design lets the overflow spill away outside rather than flooding the kitchen.
A short-lived program, such as a scheduled job, may finish before its background worker sends the last batch. Always make sure the program flushes and shuts down the exporter before ending, or the final and most interesting data may vanish.
13Security of Exported Data
Telemetry often contains sensitive details, so the road it travels must be protected.
Telemetry may look harmless, but it can reveal internal service names, user identifiers, request addresses and sometimes fragments of private data. When an exporter sends this information across a network, it must be protected the same way any other business data is protected. Security for exporters rests on a few core practices.
Encrypt in Transit
Use TLS so that anyone listening on the network sees only scrambled bytes. Plain, unencrypted connections should be limited to local testing.
Authenticate the Sender
Backends often require a secret key or token sent along with each request. Exporters can attach these as headers, and the Collector can verify them.
Mutual Trust
In stricter environments both sides present certificates, so the backend knows who is sending and the sender knows who is receiving.
Remove Sensitive Data
Use processors in the Collector to delete or mask personal information before the exporter sends data to an external vendor.
Protect Secrets
Keys and tokens should come from secret storage or environment settings, never be written openly into shared files or source control.
Once data leaves your company through an exporter, you can no longer easily take it back. Decide what to remove before it is exported, not after.
14Monitoring the Exporter Itself
The component that reports on everything else also needs someone watching it.
There is a funny problem hiding here: who monitors the monitor? If an exporter silently fails, you lose visibility without knowing it. Dashboards simply go flat, and the quiet can be mistaken for calm. Responsible teams therefore watch the health of their export path with the same seriousness as any other critical service.
Useful things to watch include how many items were sent successfully, how many were refused by the destination, how many were dropped because a queue was full, how long each send takes, and how full the queue is at any moment. The Collector can publish many of these numbers about itself, so you can chart them and set alerts. A queue that is always almost full is an early warning that the destination is too slow or that the system needs more capacity.
Measure the sent and failed counts
A rising failure count is the clearest sign that data is not reaching its home.
Watch the queue fill level
A queue that keeps growing means data arrives faster than it can leave.
Track drops explicitly
Dropped data is invisible by nature, so a counter of drops is the only way to know it happened.
Alert on silence
If a normally busy service suddenly reports nothing, treat that as a possible exporter problem, not a happy accident.
During troubleshooting, temporarily add a console or debug exporter next to the real one. If the data appears on screen but not at the backend, you have proven the problem lies in delivery, not in instrumentation.
15Design Patterns and Anti-patterns
Teams repeat the same good ideas and the same mistakes, so it is worth learning both.
Patterns that work
The most trusted pattern is the agent plus gateway layout. A small Collector runs close to each group of applications, such as one per machine, and receives data quickly with very little delay. It forwards data to a central group of Collectors that handle heavy processing and talk to the final backends. This two-tier shape keeps applications light and centralizes control.
Another good pattern is fan-out for migration. When moving from one vendor to another, a team can export the same data to both for a while, compare the results, and switch over with confidence. Because exporters are pluggable, this takes a configuration change rather than a rewrite.
Problem
Every application is configured to send data straight to a vendor, with vendor keys copied into each service.
Why It’s Harmful
Changing vendors, rotating keys or filtering sensitive fields requires touching every service. Secrets spread widely, and a vendor outage directly affects every application.
Correct Approach
Send data from applications to a Collector using the simple standard protocol, and keep vendor exporters and secrets in the Collector only.
Problem
Using the one-by-one sending style for spans in a busy production service.
Why It’s Harmful
Each finished span triggers its own network call, which adds delay and consumes resources. Under heavy load this can slow the very application you are trying to observe.
Correct Approach
Use batching so many spans share one network call, and reserve the simple style for tests and debugging.
Problem
Leaving the console exporter switched on in production.
Why It’s Harmful
Printing large volumes of telemetry to standard output wastes resources, floods log storage, and can accidentally expose sensitive details in places never meant to hold them.
Correct Approach
Keep the console exporter for development, and use a real network exporter, optionally with a debug exporter enabled only briefly during investigations.
Problem
Ignoring the exporter’s health and assuming data is always arriving.
Why It’s Harmful
Silent failures create blind spots. Teams discover them only during an outage, when the data they need is exactly the data that is missing.
Correct Approach
Monitor sent, failed and dropped counts, watch queue levels, and alert when expected data goes quiet.
16Best Practices and Common Mistakes
A short checklist of habits that save hours of debugging later.
Use the Standard Protocol
Prefer OTLP between your applications and the Collector. It is the most widely supported and loses the least information.
Batch in Production
Group data before sending to cut network and processing overhead, and tune batch size and delay to match your traffic.
Name Your Service
Always set a clear service name in the resource, so the backend can group data correctly instead of showing an unknown service.
Flush Before Exit
Make sure programs shut down the exporter cleanly so the last batch is not lost.
Hard-code Destinations
Keep addresses and keys in configuration, so that environments can differ without code changes.
Mix Up Ports and Protocols
Confirm whether the destination expects gRPC or HTTP before pointing an exporter at it.
If you see no data at all, check the basics first: is the exporter actually enabled, is the address correct, is a firewall blocking the port, and did the program live long enough to send a batch? Most missing-data mysteries have one of these four causes.
17Advantages and Trade-offs
Every design choice has a price, and exporters are no exception.
Advantages
- Swap destinations through configuration without touching instrumentation
- Send one set of data to several places at the same time
- Avoid lock-in to any single vendor
- Keep the application fast by moving heavy work to background threads
- Reuse one standard protocol across languages and tools
- Test and debug easily with console and file exporters
Disadvantages / Trade-offs
- Batching adds a small delay before data becomes visible
- Queues use memory, and data in them can be lost if the process crashes
- More exporters and destinations mean more settings to manage
- Sending data costs network bandwidth and some CPU
- Misconfiguration can silently lose data
Balancing freshness, cost and safety
Most tuning decisions come down to three competing wishes. You want data to be fresh, so you send often. You want costs to be low, so you send in big batches. You want safety, so you keep data in large queues and retry generously. Sending very often raises cost, big batches add delay, and large queues use memory. There is no perfect setting. The skill is picking a balance that fits the importance of your system and the size of your budget.
18Real-World Examples
Seeing how organizations use exporters makes the ideas concrete.
An online retailer during a sale
Traffic jumps tenfold in minutes. The retailer’s services send OTLP to a local Collector on each machine. These Collectors absorb the burst in queues and forward data to a central tier, so the checkout service is never slowed by monitoring traffic.
A bank with strict data rules
The bank’s Collector strips account numbers and personal fields with processors, then exports only the cleaned data to an external analysis tool. A second exporter keeps a full copy in internal storage for auditors.
A company changing monitoring vendors
For one month the Collector exports the same data to the old and new vendors. Engineers compare dashboards side by side, and when they are happy, the old exporter is simply removed from the configuration.
A team running scheduled data jobs
Short batch jobs start, work for a minute, and exit. The team uses push exporters and makes each job flush before exiting, because a scraping server would likely miss such short-lived programs.
A mobile or browser application
Because browsers prefer ordinary web requests, the application exports over HTTP to a public gateway Collector. The gateway authenticates requests and filters data before it enters the internal network.
19Frequently Asked Questions
No. The backend is the system that stores and displays telemetry. The exporter is the component that delivers data to it. One is the warehouse, the other is the truck.
No. An SDK exporter can send directly to a compatible backend. A Collector is optional, though it is strongly recommended once you have many services or want central control.
Yes. You can attach several exporters in the SDK, and a Collector pipeline can list many exporters. Each receives its own copy of the data.
The data waits in a queue and the exporter retries for a while. If the queue fills up or retries run out, data is dropped to protect the application.
Traces are sent in batches soon after spans end, while metrics are collected on a regular interval, often about a minute. That interval creates a natural delay.
Neither is universally better. Both carry the same data. gRPC is efficient inside private networks, while HTTP is often easier across firewalls, proxies and browsers.
A properly configured batch exporter has very little effect, because the heavy work happens on a background thread. The one-by-one style can add noticeable overhead in busy systems.
It is a pull exporter. It exposes a page of current metric values, and a scraping server visits that page on a schedule to read them.
Add a console or debug exporter temporarily to confirm data is being produced, then check the backend and the exporter’s own success, failure and drop counts to confirm it is being delivered.
Yes. Because the contract is small, consisting of export, flush and shutdown, teams can write a custom exporter for an internal system. Before doing so, check whether the standard protocol already satisfies the need, since it is supported almost everywhere.
20Summary and Key Takeaways
We started in a restaurant kitchen where useful facts were trapped behind a wall, and we ended with a complete picture of the delivery person who carries them out. An exporter is a small, pluggable component with a clear job: take finished telemetry and deliver it to a destination. Around it sit processors that decide when to send, readers that decide when to collect, and a Collector that can host many exporters in flexible pipelines. Learn this one idea well and the rest of the OpenTelemetry pipeline becomes much easier to reason about.
Key Takeaways
- An exporter sends, it does not collect — instrumentation creates data, and the exporter delivers it to a backend, Collector, file or console.
- It is pluggable — change the destination through configuration and leave your instrumentation code alone, which is the root of vendor neutrality.
- Each signal has its own family — span, metric and log exporters exist because traces, metrics and logs behave differently.
- OTLP is the preferred language — it travels over gRPC or HTTP, and it is the safest default between applications and a Collector.
- Batching and queues protect your application — background workers send groups of data so that application threads are never kept waiting.
- Design for failure — use queues, careful retries and deliberate dropping, and always flush before a short-lived program ends.
- Secure and monitor the export path — encrypt data in transit, remove sensitive fields before leaving, and watch sent, failed and dropped counts so silent failures never hide.