Before we talk about receivers, we need to know what is being received and why it is messy.

Modern software is rarely a single program. A simple online shopping experience might involve a mobile app, a web server, a payment service, a database, a cache, and a message queue, all running on many machines at once. When a customer complains that checkout feels slow, someone has to find out which of those parts is responsible. The only way to answer that question is to have every part report on what it is doing. The information that software reports about itself is called telemetry.

The Signals: What Kind of Data Are We Talking About?

Telemetry comes in different flavors, and OpenTelemetry calls each flavor a signal. Each signal answers a different kind of question, and a healthy system usually needs several of them working together.

What Is OpenTelemetry?

OpenTelemetry, often shortened to OTel, is an open-source project hosted by the Cloud Native Computing Foundation. Its goal is to give the whole industry one common, vendor-neutral way to create, collect, and send telemetry. It includes programming-language libraries that applications use to produce data, a shared data format and network protocol called OTLP, naming rules called semantic conventions, and a standalone program called the Collector.

The Collector is the piece that sits between your software and the tools where you eventually look at your data. And inside the Collector, the very first stop for every piece of data is a receiver.

The Problem of Many Languages

Here is the catch: not everything speaks the same language. Some applications use OpenTelemetry libraries and send OTLP. Older systems expose metrics in the Prometheus style. Some write logs to plain files. Others send traces in Jaeger or Zipkin formats. A database might only offer a status page. If your observability tools had to understand every one of these dialects, they would become huge and fragile.

The Collector solves this by using receivers as translators at the entrance. Each receiver knows one dialect or one way of collecting data, and it converts what it gets into a single internal format. Everything after that point can be dialect-free.

A receiver is how data gets into the Collector, whether it is pushed in or pulled in.

A receiver is a component of the OpenTelemetry Collector whose job is to get telemetry data into the Collector. That is the whole definition, and every detail in this guide builds on it. A receiver is always the first component in a data pipeline. Nothing can be processed, filtered, or exported until some receiver has first brought the data in.

Why does this component exist at all? Because collecting data is a different problem from processing it or sending it away. By giving collection its own dedicated component, the Collector can support dozens of data sources without changing anything else. You can add a new way of collecting data without touching how data is cleaned or delivered. This separation of duties is one of the main reasons the Collector is so flexible.

What a Receiver Does and Does Not Do

A receiver listens for incoming data or reaches out to collect it, understands the original format, and converts the data into the Collector’s internal representation. It then hands the converted data to the next component in the pipeline and reports success or failure back to the sender where that makes sense.

A receiver does not decide which data to keep, does not rename or enrich fields in a meaningful way, and does not talk to your final backend. Those jobs belong to processors and exporters. Keeping receivers focused on the single job of getting data in is what keeps them simple and reliable.

Receivers Are Plug-ins

The Collector itself is a small core that knows how to run pipelines. Receivers are plug-ins that you choose to include. There are receivers for network protocols, for reading files, for scraping metrics endpoints, for pulling statistics from databases, for consuming messages from queues, and for reading from cloud services. You simply pick the ones that match the systems you run.

Receivers and Resource Details

Telemetry is far more useful when you know exactly where it came from. A measurement of “high memory use” means little unless you also know which machine, which service, and which version produced it. OpenTelemetry carries this information as resource details attached to the data. Receivers that collect data from a specific source, such as a host or a database, usually attach descriptive details about that source as they bring the data in. Receivers that accept data from applications generally preserve whatever details the application already attached.

This matters because later components, such as processors that group or route data, depend on those details. A receiver that preserves them faithfully gives the rest of the pipeline reliable information to work with.

Receivers Compared with Instrumentation

Beginners sometimes confuse the receiver with the code inside the application that creates telemetry. These are two different things on opposite sides of a connection. Instrumentation lives inside your application and creates the data. The receiver lives inside the Collector, a separate program, and collects it. One side produces, the other side catches. Keeping this picture in mind prevents many misunderstandings when you read documentation or search for help.

A receiver is one of five kinds of building blocks inside the Collector.

To see where a receiver fits, we need to look at the whole Collector. The Collector is built from a small number of component types. Each type has a clear role, and together they form pipelines that data flows through from entrance to exit.

flowchart LR
  A["Apps, servers, databases"] --> B["Receiver"]
  B --> C["Processor"]
  C --> D["Exporter"]
  D --> E["Backend tools"]
        

What Is a Pipeline?

A pipeline is a named route that data follows through the Collector. Each pipeline handles one type of signal, so you will typically have one for traces, one for metrics, and one for logs. A pipeline lists which receivers feed it, which processors act on the data in order, and which exporters deliver the result.

This is an important idea: the receiver is only part of the story, and it becomes useful only when it is placed inside a pipeline. The pipeline is the plumbing; the receiver is the tap where water enters.

Why Processors and Exporters Never Meet the Outside World Directly

Because receivers do all the translating at the entrance, processors can be written once and work for data from any source. A processor that removes sensitive fields does not care whether the data came from an OTLP application, a Prometheus endpoint, or a log file. Likewise, exporters receive clean, uniform data and can focus entirely on delivering it. This design means the number of components you need grows slowly, even as the number of systems you monitor grows quickly.

Some data arrives at the door by itself; other data has to be fetched.

Every receiver falls into one of two broad styles, and knowing which is which makes configuration much easier to understand. In the push style, the source of the data sends it to the receiver. In the pull style, the receiver goes out and asks the source for it.

flowchart LR
  subgraph Push
    A1["Application with SDK"] -->|"sends data"| R1["OTLP receiver"]
  end
  subgraph Pull
    R2["Prometheus receiver"] -->|"asks on a schedule"| T2["Metrics endpoint"]
  end
        

Push Receivers

A push receiver opens a network address and waits. Applications, agents, or other Collectors connect and send data whenever they have some. The OTLP receiver is the best-known example, and the Jaeger and Zipkin receivers for traces work the same way. The advantage is timeliness: data arrives the moment it is ready. The responsibility on the receiver’s side is to be always available and to cope with bursts.

Pull Receivers

A pull receiver works on a timetable. Every so often it reads a file, queries a database, scrapes a web endpoint, or asks the operating system for statistics. The Prometheus receiver scrapes metrics endpoints, the host metrics receiver reads machine statistics, and the file log receiver reads new lines from log files. The advantage is that the source system does not need to know anything about OpenTelemetry. It only needs to expose something the receiver can read.

How to Decide Which Style You Need

Usually you do not get to choose; the source decides for you. If your application already uses an OpenTelemetry library, it will push data, so you need a push receiver. If you want statistics from a database or an operating system that has no idea what OpenTelemetry is, you need a pull receiver that knows how to ask it politely. Occasionally both are possible, as with systems that expose metrics for scraping and can also push them. In that case, consider who should control timing. Pull gives the Collector control over how often the source is contacted, which protects fragile systems from being flooded. Push gives the source control, which gives fresher data and removes the need for the Collector to know where every source lives.

Another practical point is discovery. A pull receiver must know the addresses of the things it collects from, which is easy for a handful of servers and harder for fast-changing container fleets. Some pull receivers can find their targets automatically by asking the platform what is currently running. A push receiver has the opposite advantage: it has one fixed address, and new senders simply start sending to it with no registration needed.

There are far more receivers than most people expect, and they fall into a few natural groups.

The Collector ecosystem offers a large catalog of receivers. You do not need to learn them all. It helps to think in families, where each family covers one kind of source. Once you know the families, you can quickly guess which receiver you need for a given system.

Where Do These Receivers Come From?

The OpenTelemetry project publishes the Collector in several forms. A small core distribution includes a limited, carefully maintained set of components. A larger contrib distribution includes a very wide range of community-contributed receivers. Teams that want a lean, secure build can also assemble a custom Collector containing only the receivers they need. We will return to this choice in a later chapter.

The most important receiver to understand is the one that speaks OpenTelemetry’s own language.

OTLP stands for OpenTelemetry Protocol. It is the standard way for OpenTelemetry components to exchange traces, metrics, and logs. The OTLP receiver is the Collector’s component that accepts data in this format. Because OpenTelemetry libraries for many programming languages already know how to send OTLP, this receiver is usually the main entrance of a Collector.

Two Doors: gRPC and HTTP

The OTLP receiver can accept data over two transport styles. The first is gRPC, a fast, efficient way for programs to call each other over a network. The second is plain HTTP, which is simpler to pass through firewalls, proxies, and load balancers, and which can even be used from web browsers with the right settings. By convention, the gRPC door listens on port 4317 and the HTTP door on port 4318.

Why OTLP Is the Preferred Choice

OTLP was designed together with the data model that the Collector uses internally. That means translating OTLP into the internal format loses almost nothing. Other formats sometimes have fields that do not map neatly, or lack information that OpenTelemetry can carry. When you have a choice, sending OTLP from your applications avoids translation surprises.

One Receiver, Many Signals

A single OTLP receiver can serve traces, metrics, and logs at once. It does not need a separate instance per signal. Which signals actually flow depends on which pipelines reference the receiver. If the receiver appears in a traces pipeline and a metrics pipeline but not a logs pipeline, then incoming logs will not have anywhere to go.

Let us open the hood and follow what a receiver actually does from start to finish.

Whatever its type, almost every receiver follows the same general life story. It is created, it is started, it spends its life collecting data and passing it along, and eventually it is shut down cleanly. Understanding this life story helps you reason about start-up errors, shutdown behavior, and data loss.

flowchart TD
  A["Data source or network"] --> B["Listen or scrape"]
  B --> C["Decode the original format"]
  C --> D["Convert to internal format"]
  D --> E["Pass to next component"]
  E --> F["Reply or acknowledge to sender"]
        

Scraper-Style Receivers

Some pull receivers are organized as a collection of small scrapers. The host metrics receiver is the classic example: it has separate scrapers for CPU, memory, disk, and network, and you can turn each one on or off. Think of it as one receiver that contains several little workers, each responsible for one topic. All of them share one collection interval and feed the same pipeline.

Following a single batch of data end to end shows how the receiver cooperates with its neighbors.

Let us trace what happens when an application sends a batch of trace data to an OTLP receiver. This walk-through highlights an idea that surprises many beginners: the receiver does not work alone. What happens downstream can affect what the receiver tells the sender.

sequenceDiagram
  participant App as Application
  participant Rec as Receiver
  participant Proc as Processor
  participant Exp as Exporter
  participant Back as Backend
  App->>Rec: Send a batch of data
  Rec->>Rec: Decode and convert
  Rec->>Proc: Pass the data on
  Proc->>Exp: Pass processed data
  Exp->>Back: Deliver to backend
  Rec-->>App: Report success or failure
        

Success, Failure, and Backpressure

When the next component in the pipeline accepts the data, the receiver can tell the sender that everything went fine. When the next component cannot accept it, for example because memory is running short, it returns an error. The receiver then passes that error back to the sender. A well-behaved sender can respond by waiting and trying again later.

This flow of “slow down” signals backward through the pipeline is called backpressure. It is a safety valve. Without it, a Collector under heavy load would simply keep swallowing data until it ran out of memory and crashed, losing everything at once.

Retryable and Permanent Errors

Not all failures are equal. A temporary problem, such as a full buffer, is worth retrying because it will probably clear up. A permanent problem, such as data that is malformed and can never be understood, should not be retried because it will fail every time. Good receivers and senders distinguish between the two. This distinction protects you from endless retry loops that burn resources without ever succeeding.

Why Batching Helps Receivers

Senders usually do not transmit every single span or log line separately. Doing so would create enormous network overhead, like mailing each page of a book in its own envelope. Instead, they collect many items into a batch and send them together. A receiver therefore usually decodes a batch holding hundreds or thousands of items in one request. This is far more efficient for both sides, and it is also why receiver limits are usually expressed as message sizes rather than counts of individual items.

Inside the Collector, a batching processor can regroup data again before export, so that the outgoing batches are a size the backend likes. The receiver does not need to worry about that; it simply accepts whatever batch size arrives, within its configured limits.

The Pull Case

A pull receiver has no remote sender to answer, but the same principle applies in a different form. If the pipeline cannot accept scraped data, the receiver may drop that round of data or log a problem, and it will try again on the next interval. Since pulled data is typically a regular series of measurements, one missed round usually leaves a small gap rather than a catastrophe.

Receivers and pipelines have a flexible many-to-many relationship.

One of the most useful facts about receivers is how freely they can be combined with pipelines. A pipeline may have several receivers feeding into it, and a single receiver may feed several pipelines. This is what lets a small number of components serve a very large variety of needs.

flowchart LR
  R1["OTLP receiver"] --> P1["Traces pipeline"]
  R1 --> P2["Metrics pipeline"]
  R1 --> P3["Logs pipeline"]
  R2["Prometheus receiver"] --> P2
  R3["File log receiver"] --> P3
        

Several Receivers into One Pipeline

Imagine your metrics pipeline needs data from both OpenTelemetry-ready applications and older systems that expose Prometheus-style endpoints. You list both the OTLP receiver and the Prometheus receiver in the same metrics pipeline. Their data merges into one stream before reaching the processors. The processors do not need to know that two different sources exist.

One Receiver into Several Pipelines

The same receiver can also appear in more than one pipeline, as long as the pipelines handle signals that the receiver supports. When a receiver feeds two pipelines of the same signal type, each pipeline gets its own copy of the data. This fan-out is useful when you want to send the same traces to two destinations processed in two different ways, for example one copy with sensitive fields removed for a third-party vendor and one full copy for internal use.

Naming Multiple Instances

Sometimes you want two receivers of the same type with different settings. For example, one OTLP receiver might listen on an internal network address while another listens on a public-facing address with stricter security. The Collector allows this by letting you give each instance its own name after the type. They behave as completely independent receivers even though they share the same type.

You do not need to memorize any settings yet; you just need to know what kinds of choices exist.

Every receiver is customized through its configuration. The exact names differ from receiver to receiver, but the kinds of decisions are surprisingly similar across all of them. Learning these categories gives you a mental checklist to run whenever you set up or review a receiver.

Choosing a Good Listening Address

The address a receiver listens on has a large effect on security. Listening on all network interfaces makes the receiver reachable from anywhere the network allows. Listening only on the local machine makes it reachable only by programs on that same machine. Recent versions of the Collector lean toward the safer local-only behavior by default, because exposing an unauthenticated receiver to a wide network is a common mistake. Whatever your version does, it is wise to choose the address deliberately rather than trusting defaults.

Choosing a Good Collection Interval

For pull receivers, the interval is a trade-off. A very short interval, such as every second, gives you detailed and timely data but increases the work done by both the Collector and the source system. A long interval reduces load but can hide short spikes. Many teams start with an interval of around fifteen to sixty seconds for general metrics and tighten it only for the few things that truly need it.

The same receiver behaves differently depending on where the Collector is placed.

A Collector can be deployed in several ways, and receivers play a slightly different role in each. The two most common patterns are the agent and the gateway. Many production systems use both together.

flowchart LR
  A1["Service A"] --> AG1["Agent Collector"]
  A2["Service B"] --> AG1
  A3["Service C"] --> AG2["Agent Collector"]
  AG1 --> GW["Gateway Collector"]
  AG2 --> GW
  GW --> BE["Backend tools"]
        

The Agent Pattern

An agent is a Collector that runs close to your applications, for example on the same machine or as a helper next to each group of containers. Its receivers accept data from nearby applications over very short network hops, and its pull receivers can read local resources such as host statistics and log files. Because it sits next to the workload, it can quickly take data off the application’s hands so the application is not slowed down.

The Gateway Pattern

A gateway is a central Collector, or a pool of them, that receives data from many agents or applications. Its receivers are typically OTLP receivers, since agents send OTLP onward. The gateway is a good place for heavy processing, sampling decisions, and a single controlled exit to the outside world. It means individual applications and agents do not each need credentials for the final backend.

Which receivers are available to you depends on which Collector build you run.

A receiver can only be used if it is compiled into the Collector you are running. This is why the different Collector builds exist, and why choosing among them is a real design decision rather than a technicality.

Why a Custom Build Is Often the Best Production Choice

Every component you include is code that has to be kept updated and trusted. A Collector that contains hundreds of receivers you never use carries a larger surface for security issues and a larger size on disk. A custom build includes only what you need, which makes it smaller, easier to audit, and quicker to start. Many security-conscious organizations treat the contrib build as a place to experiment and a custom build as the thing they actually deploy.

Stability Levels

Not every receiver is equally mature. Each component carries a stability label for each signal it supports, ranging from early development, through alpha and beta, to stable. A stable label means the project promises to avoid sudden breaking changes. A lower label means settings or behavior may change between releases. Before relying on a receiver for something important, check how mature it is for the particular signal you use.

A receiver is a door, and every door needs a lock.

Because push receivers accept connections from the network, they are the most exposed part of a Collector. Pull receivers carry their own risks, since they often hold credentials to read from databases and other systems. Security for receivers is therefore not optional, and it is best thought about in layers.

Layer 1: Limit Who Can Reach the Door

The first layer is the network itself. Choose listening addresses carefully, use firewalls or network policies to allow only expected senders, and avoid exposing receivers directly to the internet unless you truly must. Many security problems disappear when a receiver is simply not reachable by strangers.

Layer 2: Encrypt the Conversation

Telemetry often contains sensitive details such as user identifiers, internal service names, and sometimes fragments of data inside error messages. Encrypting the connection with TLS prevents eavesdropping on the network. For stronger protection, mutual TLS makes both sides present certificates, so the receiver also knows that the sender is legitimate.

Layer 3: Verify Who Is Sending

Authentication extensions can be attached to receivers so that each incoming request must carry valid proof of identity, such as a token or credentials. Requests that fail the check are rejected before their data enters the pipeline. This is especially important for receivers that face public networks.

Layer 4: Protect Against Overload and Abuse

Size limits on messages, memory limiting in the pipeline, and sensible concurrency settings keep a single noisy or malicious sender from overwhelming the Collector. For receivers used by browser applications, cross-origin rules control which websites are allowed to send data, so that random pages cannot flood your endpoint.

The Collector watches your systems, but who watches the Collector?

It is easy to forget that the Collector is itself a piece of software that can fail, slow down, or become overloaded. If a receiver silently drops data, you might look at an empty dashboard and wrongly conclude that everything is quiet. That is why the Collector produces telemetry about its own behavior, including detailed numbers about each receiver.

The Numbers That Matter Most

The Collector’s own metrics include counts of how much data each receiver accepted and how much it refused, broken down by signal type. For example, there are separate counters for accepted and refused spans, metric points, and log records. These names typically begin with a Collector-specific prefix followed by the word receiver. Traditionally these self-metrics are exposed in the Prometheus style on a dedicated port, although the exact setup depends on the Collector version and your configuration.

A Simple Troubleshooting Routine

Seeing receivers in realistic situations makes the concepts concrete.

The best way to appreciate receivers is to see the kinds of problems they solve in everyday engineering work. The scenarios below are common patterns, simplified so they are easy to follow.

The receiver design is powerful, but like every design it has costs.

Separating data collection into dedicated receivers is a deliberate design choice. It brings large benefits, but it also introduces things you must plan for. A balanced view helps you decide where the model fits best.

When the Trade-offs Tip the Balance

For a tiny project with a single application, sending data directly from the application to a backend can be simpler, and a Collector may be unnecessary overhead. As soon as you have several services, several data formats, or a need for central control, the benefits of receivers quickly outweigh the cost of running a Collector. Most growing systems cross that line sooner than they expect.

A short list of habits that prevent most beginner problems.

Habits Worth Building

Mistakes to Avoid

Quick answers to the questions beginners ask most often.

No. They are opposites. A receiver brings data into the Collector, while an exporter sends data out of it. Data enters through a receiver and leaves through an exporter.

Every pipeline needs at least one receiver, because a pipeline with no source has nothing to carry. The only exception is a receiver supplied by a connector, which takes data from the end of another pipeline.

Yes, if that receiver supports those signals. The OTLP receiver supports all three. Which ones actually flow depends on which pipelines reference the receiver.

Common causes include the receiver not being listed in any pipeline, a sender pointed at the wrong port or protocol, a network block, processors that filter everything out, or an exporter that is failing. Check the receiver’s accepted and refused counts first to learn whether data is arriving at all.

An SDK is a library inside your application that creates telemetry and sends it out. A receiver is part of the Collector, a separate program, and accepts or collects data. The SDK’s exporter often sends to the Collector’s receiver, so they are two ends of the same connection.

Yes, by giving each a distinct name. Remember that push receivers cannot share the same address and port.

No. A receiver is a pass-through. It accepts data and hands it to the next component. Any buffering happens elsewhere, such as in processors or exporter queues, and long-term storage belongs to your backend.

The OTLP receiver. It is the standard entrance, it is used between Collectors, and understanding it makes every other receiver easier to grasp.

A receiver converts data from its original format into the Collector’s internal format, and pull receivers may attach descriptive details about the source. Deliberate changes such as filtering, renaming, or removing fields are the job of processors.

For a small setup, sending directly can work. Once you have several services, mixed data formats, or a wish for central security and processing, a Collector with receivers becomes very valuable.

A receiver is the front door of the OpenTelemetry Collector. It accepts telemetry that is pushed to it or pulls it from a source, understands the original format, converts the data into one common internal shape, and hands it to the rest of the pipeline. By taking on the messy job of speaking many dialects at the entrance, receivers let processors and exporters stay simple, reusable, and independent of where data came from. Learn the families, secure the doors you open, watch the accepted and refused counts, and the receiver model will serve you well from your first small Collector to a large production fleet.