The short answer first, then the details that make it useful.

OpenTelemetry, often shortened to OTel, is a free, open source framework hosted by the Cloud Native Computing Foundation. It gives developers one standard way to create and collect telemetry. But creating telemetry is only half the story. Someone has to carry it out of your program or out of the middle layer and deliver it to a place where people can use it. That carrier is the exporter.

A vendor is simply a company that sells or hosts a product, such as a monitoring service, a log search tool, or a cloud platform. A vendor exporter is an exporter built to deliver telemetry to one particular vendor’s product, using that vendor’s own data format, address, and rules. It is the special envelope that only one courier accepts.

The other kind of exporter is the OTLP exporter. OTLP stands for OpenTelemetry Protocol, the project’s own standard language. An OTLP exporter works with anyone who understands that language, which today includes a large and growing number of vendors and open source tools. It is the standard international envelope.

What a vendor exporter usually does

• Translates. It converts OpenTelemetry’s internal data into the exact format the vendor expects.
• Addresses. It knows the vendor’s web addresses, called endpoints, including regional variations.
• Authenticates. It attaches the secret key or token that proves you are a paying customer.
• Adapts. It handles quirks, such as how the vendor wants metrics measured or how names must be spelled.
• Delivers reliably. It retries on failure and queues data during short outages.

What a vendor exporter is not

A vendor exporter is not a backend. It does not store or display anything; it only delivers. It is also not required, because most modern vendors accept the standard OTLP format, so the plain OTLP exporter often works just as well. And it is not a separate product from OpenTelemetry. Most vendor exporters are components that live inside the OpenTelemetry project’s own code repositories, usually built and maintained by people from the vendor itself.

Why you should care about exporters

Exporters sit at the very end of the telemetry journey, which makes them easy to ignore until something goes wrong. Yet every dashboard, alert, and investigation you will ever run depends on data that an exporter delivered. If the exporter is misconfigured, slow, or sending the wrong thing, even the best instrumentation in the world will leave you blind.

Exporters also decide how much freedom you keep. A well-chosen exporter lets you change tools without drama, while a carelessly chosen one can quietly turn a flexible system into a rigid one. Understanding them early is one of the cheapest ways to protect your future options.

Every good component begins as a response to a painful problem. Vendor exporters are no exception.

When tracing and monitoring tools first appeared, every vendor invented its own way of receiving data. One product wanted data in one shape, a second wanted it in another, and a third required a completely different set of field names. A company that wanted to switch from one product to another often had to rewrite the instrumentation code inside every application, which could take months.

The earlier open source projects, OpenTracing and OpenCensus, tried to soften this problem. OpenCensus in particular shipped many exporters, each one a small translator for a specific destination. The idea was good: write your instrumentation once, and choose the destination by swapping an exporter. Still, every vendor had its own exporter with its own behavior, and every language had its own set. The number of combinations grew quickly.

In 2019, OpenTracing and OpenCensus merged into OpenTelemetry. The new project kept the idea of exporters and added something even more powerful: a single standard protocol, OTLP, that vendors could accept directly. Over the following years, vendor after vendor added native OTLP support to their products. When a vendor accepts OTLP directly, the plain OTLP exporter is enough, and a custom vendor exporter becomes optional.

It is worth understanding how vendor exporters come into being. In most cases, a vendor writes the exporter for its own product and offers it to the open source project. Volunteers and project maintainers review it, and once accepted, it is named in a file that lists its code owners, the people responsible for keeping it healthy. This arrangement is efficient, because the people who know the vendor’s system best write the translation. It also means the exporter’s quality depends on how much attention the vendor and the community give it over time.

A handful of words explain nearly everything in this area. Let us meet them one at a time.

SDK exporter versus Collector exporter

Exporters exist in two places. An SDK exporter lives inside your application and sends data straight from your program. A Collector exporter lives inside the Collector and sends data onward from the middle layer. In practice, applications almost always use the standard OTLP exporter in the SDK to talk to a Collector, while the Collector, where they exist, uses vendor exporters or OTLP exporters to talk to the final destinations. We will see why this split is so helpful.

A word about distributions

Some vendors publish their own ready-to-use package of OpenTelemetry, called a distribution. It is the standard project plus the vendor’s preferred settings and extra components, so customers can get started quickly. Examples include distributions offered by large cloud providers and observability companies. A distribution is convenient, but it is worth remembering that it can bring vendor-specific habits along with it, so read what is inside before you rely on it.

Resource details travel with the data

Telemetry does not travel alone. It carries a description of who produced it, called the resource, with details such as the service name, the version, and the environment. Vendor exporters use these details to decide where to file the data in the vendor’s own screens. If the service name is missing or wrong, the data may appear under an unhelpful label such as “unknown service,” and nobody will find it. Setting the resource details carefully in your applications is therefore one of the quietest, most valuable habits in the whole pipeline.

Vendor exporters are one branch of a larger family. Seeing the whole family makes each branch easier to understand.

OpenTelemetry offers many exporters, and they fall into four rough groups. The standard group contains the OTLP exporters, which are neutral. The open source backend group contains exporters for community tools, such as Prometheus, Zipkin, and Kafka. The vendor group contains exporters aimed at commercial products and cloud platforms. The helper group contains exporters that exist for testing and plumbing rather than for a final destination.

flowchart TD
    EXP["Exporters"]
    EXP --> STD["Standard and neutral"]
    EXP --> OSS["Open source backend exporters"]
    EXP --> VEN["Vendor exporters"]
    EXP --> HLP["Helper exporters"]
    STD --> S1["OTLP over gRPC"]
    STD --> S2["OTLP over HTTP"]
    OSS --> O1["Prometheus"]
    OSS --> O2["Zipkin"]
    OSS --> O3["Kafka"]
    VEN --> V1["Datadog"]
    VEN --> V2["Splunk"]
    VEN --> V3["AWS X-Ray"]
    VEN --> V4["Google Cloud"]
    VEN --> V5["Azure Monitor"]
    HLP --> H1["Debug or console"]
    HLP --> H2["File"]
    HLP --> H3["Load balancing"]

Read the diagram from the top. Every exporter does the same basic job, which is to send telemetry out, but each branch has a different purpose. The standard branch is the neutral path that works with anyone who speaks OTLP. The open source branch serves community tools. The vendor branch serves specific companies. The helper branch is about testing, saving data to a file, or spreading work among several Collectors. The names in the vendor branch are examples only, because the exact list changes over time.

Where you attach an exporter matters just as much as which exporter you choose.

The usual recommended design is simple. Applications use the SDK and send data in OTLP to a Collector. The Collector receives it, applies shared rules in its processors, and then uses exporters, either OTLP or vendor, to deliver it to one or more destinations. Because the choice of destination is made in the Collector, applications never need to know which vendor is in use.

flowchart LR
    subgraph APP["Application"]
        CODE["Your code with OpenTelemetry SDK"]
        SX["SDK exporter: OTLP"]
    end
    subgraph COL["Collector"]
        RC["OTLP receiver"]
        PR["Processors"]
        VE["Vendor exporters and OTLP exporters"]
    end
    subgraph VENDORS["Destinations"]
        V1["Vendor A"]
        V2["Vendor B"]
        V3["Open source backend"]
    end
    CODE --> SX
    SX -->|OTLP| RC
    RC --> PR
    PR --> VE
    VE --> V1
    VE --> V2
    VE --> V3

Follow the arrows. The application code creates telemetry, and its SDK exporter sends it as OTLP. The Collector’s receiver accepts it, the processors clean and label it, and the exporters deliver it to Vendor A, Vendor B, and an open source backend. If the company later drops Vendor A and adds a new vendor, only the Collector changes. No application is touched.

Why not put vendor exporters inside the application?

You can, and many tutorials do, because it is the shortest path to a working demo. But it ties the application to the vendor. The vendor’s secret key must be present in every program. Changing vendors means changing and redeploying every program. A bug or slowdown in the vendor exporter runs inside your business code. And rules for sampling, redaction, and labeling must be repeated in every application. Putting vendor exporters in the Collector avoids all of these problems at once.

When SDK exporters are the right choice

Direct export from the SDK is perfectly sensible in a few situations: a small project with one service and one vendor, a quick experiment, a serverless function where running a separate Collector is awkward, or a vendor that officially recommends its own distribution. In those cases, simplicity wins, and you can move to the Collector design when the system grows.

One Collector or a chain of them

The Collector in this design can be a single shared service, or it can be a chain with a small agent on every machine feeding a central gateway. In both layouts, exporters at the final step are the ones that touch the outside world. It usually makes sense to put vendor exporters only on the final, central layer. This keeps the number of places that hold secret keys small, and it means the outbound connections to the vendor come from a few well-known machines, which makes network rules and monitoring far simpler.

Follow one bundle of telemetry on its final journey, from the Collector to the vendor.

sequenceDiagram
    participant P as Processors
    participant X as Vendor exporter
    participant Q as Sending queue
    participant V as Vendor endpoint
    P->>X: 1. Hand over batch in OpenTelemetry format
    X->>X: 2. Translate to vendor format and add key
    X->>Q: 3. Place request in queue
    Q->>V: 4. Send over encrypted connection
    V--xQ: 5. Temporary error or rate limit
    Note over Q: 6. Wait and retry with growing delay
    Q->>V: 7. Retry the request
    V-->>Q: 8. Accepted
    Note over X: 9. Count sent and failed items

In steps one to three, the processors hand over a bundle, the exporter translates it and adds the key, and the request enters the queue. In step four the queue sends it to the vendor. Step five shows a common real-world event: the vendor says “slow down” or is briefly unavailable. Rather than discarding the data, the queue waits and retries with growing pauses, as steps six and seven show. When the vendor accepts in step eight, the work is done, and in step nine the exporter counts what was sent and what failed so that you can watch it on a dashboard.

Notice also that an exporter works on copies of the data in memory. It does not change your applications and it does not change the original telemetry. If you attach two exporters to one pipeline, each performs its own translation from the same starting point, and each can fail or succeed on its own. That independence is what lets one vendor be slow or unavailable while the other keeps receiving data happily.

Translation is the heart of it

The translating step is the reason vendor exporters exist at all. OpenTelemetry uses agreed names for common details, called semantic conventions. For example, there is one agreed name for the service that produced the data. A vendor may use a different name for the same idea, or may treat a few special details in a unique way. The vendor exporter maps one to the other. Good exporters do this faithfully, but translation can lose information or rename things in surprising ways, which is why it is worth checking your data in the vendor’s screens after the first test.

Batches and size limits

Vendors set limits on how large a single request may be, how many items it may hold, and how fast requests may arrive. A batch processor ahead of the exporter groups data into efficient bundles, and its size settings should respect the vendor’s limits. If bundles are too large, the vendor may refuse them whole. If they are too small, you waste effort and may hit rate limits. When the vendor documents its limits, treat them as the starting point for your batch settings.

This is the question every team eventually asks, and the answer is usually simpler than it first appears.

The project’s general advice is easy to remember: use OTLP whenever the destination supports it. OTLP is the native language of OpenTelemetry, so nothing needs to be translated, and nothing can be lost in translation. It also keeps you free to change destinations, because every OTLP-speaking product looks the same from the outside.

Vendor exporters earn their place in the remaining cases. Some destinations simply do not accept OTLP yet. Some cloud platforms tie access to their own identity system, so an exporter that understands that system is much easier to use. And some products offer special features that only their own format can carry. The flowchart below turns this thinking into a short decision path.

flowchart TD
    A["Need to send data to a vendor"] --> B{"Does the vendor accept OTLP directly?"}
    B -->|Yes| C["Use the standard OTLP exporter with the vendor endpoint and key"]
    B -->|No| D{"Is there a vendor exporter for the Collector?"}
    D -->|Yes| E["Use it and check its stability level"]
    D -->|No| F["Use the vendor distribution or choose another path"]
    E --> G{"Is the exporter stable enough for your needs?"}
    G -->|Yes| H["Adopt it and monitor it"]
    G -->|No| I["Test carefully or ask the vendor for support"]

Begin at the top. If the vendor accepts OTLP directly, you are done: use the standard exporter and point it at the vendor’s endpoint with your key. If not, look for a vendor exporter in the Collector collection. If one exists, check how mature it is. A component labeled stable is much safer than one labeled development or alpha, which may change or disappear without much warning. If no exporter exists at all, consider the vendor’s own distribution or reconsider the choice of destination.

Cloud platforms deserve a special mention. Their monitoring services are closely tied to their own identity and permission systems. A vendor exporter built for such a platform can ask the platform for short-lived proof of identity, which avoids storing a secret key at all. For organizations that run entirely on one cloud, this convenience and safety is often the deciding reason to use the platform’s exporter, even though plain OTLP might also be possible.

Every exporter, whether OTLP or vendor, is controlled by a small set of settings. Learn them once and you can read any exporter.

Most exporters have the same basic dials. Some are required, such as where to send and how to prove who you are. Others tune reliability and performance. The table below explains each dial in plain language.

It helps to remember that settings come in layers. Some belong to the exporter itself, such as the endpoint and the key. Others belong to the surrounding pipeline, such as the batch size and the processors that run before the exporter. A problem that looks like an exporter failure is sometimes caused by a neighbor in the pipeline, for example a processor that removes a label the vendor requires. When something goes wrong, check the whole path, not only the last step.

Which settings matter most on day one

For a first working setup you need three things: the right endpoint, a valid credential, and encryption turned on. Everything else can start at its default. Once data is flowing, spend time on the reliability dials, especially the queue and the retries, because these decide what happens on the first bad day.

Keep secrets out of the settings file

The configuration file is usually stored in a shared place and read by many people. A secret key typed directly into it can leak through version control, screenshots, or support tickets. A better habit is to keep the key in a proper secret store and let the Collector read it from the environment when it starts. The file then contains only a reference, and the secret lives somewhere safer.

One exporter, several pipelines

A single exporter can be used by several pipelines, and a single pipeline can send to several exporters. This flexibility is what makes tasks such as copying data to a second vendor easy. It also means that a careless change to a shared exporter affects every pipeline that uses it, so treat shared settings with respect.

Compression and bandwidth

Telemetry can be bulky, and sending it across the internet costs both time and money. Most exporters can compress data before sending, trading a little processing effort for a large saving in network traffic. This is usually a good bargain, particularly when the Collector sits in one cloud region and the vendor in another, where data transfer is charged. Check that the vendor accepts the compression style you choose, and measure the effect on both bandwidth and processor use after turning it on.

Traces and logs usually travel smoothly. Metrics have a few traps that every vendor exporter user should know.

Metrics are numbers measured over time, such as the count of requests handled. Different destinations expect these numbers to be reported in different styles, and a vendor exporter often has to adapt. The most important difference is called temporality.

Some backends, such as Prometheus, expect cumulative totals. Others prefer or require deltas. The Collector offers processors that convert between the two, and some vendor exporters apply the right style automatically. If a counter on your dashboard suddenly looks flat, impossible, or wildly spiky, a mismatch in temporality is the first thing to suspect.

Units deserve a short word as well. A duration may be measured in seconds by one system and milliseconds by another, and a size may be in bytes or kilobytes. Exporters usually carry the unit along, but not every destination displays it the way you expect. A chart that shows latency of two thousand when you expected two is almost always a unit mismatch, not a sudden disaster, so check the unit before sounding the alarm.

Cardinality and the bill

Cardinality means the number of different combinations of label values. If a metric has a label for the customer ID, and you have a million customers, that single metric becomes a million separate lines. Many vendors bill by the number of such lines, so one careless label can multiply costs overnight. A gateway Collector with a processor that drops or merges unbounded labels is one of the best defenses.

An exporter is the exit door of your telemetry. Whatever passes through it leaves your control.

Exporters carry two kinds of valuable things: the telemetry itself, which may contain sensitive details about your system and your customers, and the credentials that let you send it. Both deserve care. A good rule is to assume that anything an exporter sends will be stored by a third party for a long time, and to decide, before turning it on, whether you are comfortable with that.

Using cloud identity instead of static keys

Some vendor exporters, especially those for large cloud platforms, can use the cloud’s own identity system. The Collector is given a role, and the platform proves who it is automatically, without any long-lived secret in a file. This is usually safer than a static key, because there is nothing to leak or forget to rotate. When a vendor offers this option, it is often the best reason to prefer the vendor exporter over plain OTLP.

Review what you export

Make it a habit to look at a sample of exported data from time to time, as a stranger would see it. Ask whether a person could be identified, whether a secret is visible, and whether anything leaves that the company never agreed to share. A short review each quarter often finds forgotten attributes, such as a full web address with an access token in it, long before an auditor or an attacker does.

If the delivery truck breaks down, the warehouse keeps working and nobody notices until the shelves are empty. Watch the trucks.

An exporter that quietly fails produces the most dangerous kind of problem: dashboards that look calm because they are empty. To avoid this, the Collector publishes internal telemetry about its own work, including metrics for how many items each exporter sent, how many failed, and how full its queue is. Collect these numbers, chart them, and set alerts.

The debug exporter: your testing friend

The Collector has a helper called the debug exporter, earlier named the logging exporter. It prints a summary of the telemetry passing through into the Collector’s own log. Adding it temporarily next to a vendor exporter lets you confirm that the data looks right before it leaves, which makes it much easier to tell whether a problem is in your pipeline or on the vendor’s side. Remove it, or lower its detail, in production, because it can create a lot of log output.

Check the other end too

Counting what you sent is only half the story. Once in a while, open the vendor’s own screens and confirm that the data arrived and looks as expected: service names, labels, units, and timestamps. A comparison between the Collector’s sent counts and the vendor’s received counts reveals problems that no single side can show.

A useful dashboard for exporters shows four lines side by side: items received by the Collector, items processed, items sent, and items failed. If the first line is healthy but the third is low, you know the problem is between the Collector and the vendor. If the first line itself is low, the problem is upstream in the applications. This simple layout turns a mysterious blank screen into a clear question about which stage to investigate.

Every choice has a price. An honest view helps you decide when a vendor exporter is the right tool.

Common trade-offs in plain language

When you weigh the costs, count more than the price of the vendor’s bill. Include the time spent learning each exporter’s settings, the effort of upgrading it, and the risk that it changes or is retired. A component that is free to download can still be expensive to own. The standard exporter usually has the lowest total cost of ownership, because it changes slowly and behaves the same everywhere.

Patterns are tried-and-true recipes. Habits are the small routines that keep your exporters dependable and your options open.

The migration pattern in pictures

Changing vendors is frightening when it means rewriting applications. With a Collector in the middle, it becomes a careful experiment. You add the new vendor as a second destination, compare what both show, and remove the old one when you are ready.

flowchart LR
    APPS["Applications sending OTLP"] --> GW["Gateway Collector"]
    GW -->|"full stream"| OLD["Current vendor"]
    GW -->|"copy for comparison"| NEW["New vendor"]
    OLD --> CMP["Compare results"]
    NEW --> CMP
    CMP --> DEC{"Happy with the new vendor?"}
    DEC -->|Yes| CUT["Stop sending to the old vendor"]
    DEC -->|Not yet| FIX["Adjust settings and keep comparing"]

Follow the arrows. All applications keep sending OTLP to the same gateway, and nothing about them changes. The gateway sends the full stream to the current vendor and a copy to the new one. The team compares dashboards, alerts, and costs. If the new vendor is not ready, they adjust settings and keep comparing. When satisfied, they stop sending to the old vendor, and the migration is complete. Because the applications never changed, rolling back is as easy as adding the old destination again.

Habits that pay off

• Prefer OTLP first. Switch to a vendor exporter only for a named reason.
• Check the stability level. Prefer stable and beta components for production. Treat alpha and development components as experiments.
• Know the maintainers. Look at who owns the component, how often it is updated, and how quickly issues are answered.
• Pin versions and read release notes. A vendor exporter can change settings between versions, so upgrade on purpose, not by accident.
• Test with real data. Verify names, units, and labels in the vendor’s screens after every significant change.
• Turn on the queue and retries. Use a disk-backed queue for data you cannot afford to lose.
• Control volume before export. Sampling, filtering, and dropping noisy labels are the cheapest cost savings you will ever make.
• Document the destination map. Write down which data goes to which vendor, under which key, and who owns each key.

Learning from other people’s mistakes is much cheaper than making your own.

An anti-pattern is a habit that looks sensible at first but causes trouble later. These four appear again and again in real exporter setups.

One further trap deserves mention. Teams sometimes build a delicate chain of renaming rules to make a vendor exporter produce exactly the names they like. Each rule seems small, but together they form a hidden layer that nobody fully understands, and it breaks quietly when either side changes. Prefer to follow the agreed semantic conventions and the vendor’s documented mappings, and add custom renaming only where it brings real value.

Myths and realities

Let us estimate how much data an exporter will carry, the way a platform engineer would, using simple arithmetic.

Imagine an online store whose services create about 30,000 spans per second at the busiest hour. About one fifth of those spans come from health checks that nobody ever reads. The team plans to keep one quarter of the remaining traces after sampling. Each span averages about one kilobyte when sent. These numbers are for illustration only; real systems must be measured.

Reading the table from the top, the filtering and sampling steps reduce the stream from 30 megabytes per second to 6 megabytes per second. That is an eighty percent reduction in the volume sent to the vendor, and, for vendors that bill by volume, a similar reduction in cost. The lesson is that the cheapest data to pay for is data you never export. Those two processing steps, done once in a central Collector, are worth far more than any clever exporter setting.

The table also warns about the migration pattern from the previous chapter. If the team sends the same stream to two vendors for comparison, the volume sent doubles for as long as the trial lasts. A common remedy is to compare using a smaller sample for the second vendor, which gives enough evidence at a fraction of the price.

The arithmetic above also helps a team talk calmly with a vendor. Instead of asking for a discount in the dark, the platform team can say how many gigabytes it expects each month and what it has done to keep that number reasonable. Vendors tend to respond better to customers who know their own data, and the team gains confidence that the bill will not surprise anyone.

Real-world scenarios

The whole story in a few simple ideas you can carry with you.