Before learning the tool, let us feel the problem it solves.

A quick reminder of the Collector

The OpenTelemetry Collector is a standalone program that receives telemetry, which is information that software sends out about itself, such as traces, metrics and logs. It can clean and reshape the data, and then forward it to storage systems, called backends. Inside the Collector, data flows through a pipeline: receivers bring data in, processors work on it, and exporters send it out.

What happens if we send every piece alone?

Think about a busy online store. It may create tens of thousands of spans every second. If the Collector sent each span to the backend in its own network request, several bad things would happen.

• Too many trips. Every network request has a fixed cost: opening a connection, adding headers, waiting for a reply. Doing this thousands of times a second wastes huge effort.
• Poor compression. Compression works by finding repeating patterns. A single tiny message has very few patterns, but a large group of similar messages compresses very well.
• Overloaded backends. Many storage systems prefer fewer, larger writes. A flood of tiny requests can slow them down, trigger rate limits, or raise your bill.
• Higher CPU use. Each send needs work, such as encoding the data and managing connections. Doing it per item multiplies that cost.

The short answer first, and then the details.

Batching in the Collector means holding incoming telemetry for a short time, grouping it into larger bundles, and then sending each bundle on together. In the Collector, this is mainly done by a processor called the batch processor. It works for all three signals: traces, metrics and logs.

The batch processor follows a very simple rule. It sends a batch when either the batch has collected enough items, or enough time has passed since the batch began, whichever happens first. This two-part rule is the heart of batching.

flowchart TD
    A["Telemetry arrives from receivers"] --> B["Batch processor collects items"]
    B --> C{"Has the batch reached the target size?"}
    C -->|Yes| D["Send batch now"]
    C -->|No| E{"Has the timeout expired?"}
    E -->|Yes| D
    E -->|No| B
    D --> F["Exporter sends batch to backend"]
    

What counts as one item?

The batch size is counted in the natural unit of each signal. For traces, it counts spans. For logs, it counts log records. For metrics, it counts data points, which are the individual measurements, and not the number of metrics. This small detail matters when you pick a size, because one metric can contain many data points.

The batch processor has only a few settings. Understanding each one is most of the skill.

The most confusing pair: send size versus max size

Beginners often think send_batch_size is a strict limit. It is not. It is a trigger. It says, “once I have at least this many items, send.” But a big group of incoming data can arrive all at once, so the batch could end up larger than that number. If you want a firm upper limit, you must set send_batch_max_size. When it is set, the processor splits large bundles so that none is bigger than the limit. The max size must be equal to or larger than the send size.

Why the max size matters in real life

Many receiving systems refuse messages that are too large. For example, a common default limit for a single network message in the gRPC technology is around four megabytes. If your batches grow bigger than the backend allows, the whole batch may be rejected, and you will lose data or waste retries. A sensible max size keeps each bundle within a safe range.

Let us follow items as they arrive over a few moments.

sequenceDiagram
    participant R as Receiver
    participant B as Batch Processor
    participant E as Exporter
    participant K as Backend
    R->>B: 3000 spans arrive
    B->>B: Hold items and start timer
    R->>B: 6000 more spans arrive
    B->>B: Total passes 8192 so size trigger fires
    B->>E: Send batch of spans
    E->>K: One network request
    R->>B: 500 spans arrive
    B->>B: Hold items and start timer
    B->>B: Timer expires with batch still small
    B->>E: Send small batch because of timeout
    E->>K: One network request
    

A separate batcher for each pipeline

Each pipeline gets its own working copy of a processor. If you list the same batch processor in two pipelines, such as traces and logs, each pipeline has its own independent batch. They do not share items. This keeps signals from mixing.

Batching by sender with metadata

Sometimes one Collector serves several customers or teams, and you must not mix their data in one batch. The batch processor can keep separate batches for each value of chosen request details, called metadata, such as a tenant ID in an incoming request header. This is powerful, but each unique value creates its own batch in memory, which is why there is a cardinality limit to protect the Collector.

Order matters, and batching has a favourite spot.

In a pipeline, every processor works on the output of the one before it. The batch processor is normally placed near the end, right before the exporters. The reason is simple: other processors may remove, change or reshape data. If you batch first and filter later, the batches become uneven and smaller than planned, and you have wasted effort.

flowchart LR
    R["Receiver"] --> M["Memory Limiter"]
    M --> E1["Enrichment"]
    E1 --> F["Filter and Redaction"]
    F --> S["Sampling"]
    S --> B["Batch"]
    B --> X["Exporter"]
    X --> BK["Backend"]
    

Four separate gains come from the same simple idea.

Many beginners do not realise that data can wait in more than one place.

After the batch processor creates a batch, the next step is the exporter. Most exporters have their own sending queue, a waiting line for batches that are ready to be sent, along with retry settings that try again when the backend is briefly unavailable. So there are two places where data waits in memory.

flowchart LR
    A["Items arrive"] --> B["Buffer 1: Batch Processor groups items"]
    B --> C["Buffer 2: Exporter sending queue holds finished batches"]
    C --> D{"Backend accepted the batch?"}
    D -->|Yes| E["Done"]
    D -->|No| F["Retry with waiting time between attempts"]
    F --> C
    F --> G["Give up after the retry limit and drop the batch"]
    

An important honest limit

Because the batch processor accepts data and then sends it later in the background, the sender who gave it the data is usually told “received” long before the data reaches the backend. If the backend later fails for long enough that retries run out, or the Collector crashes, the sender never learns that some data was lost. This is a known trade-off of batching in a processor.

The OpenTelemetry community has been working on moving batching into the exporter’s own sending queue, which can be combined with disk-based storage and gives more honest feedback to senders. This area has been changing, so check the current Collector documentation to see which approach is recommended for your version.

There is no magic number. The right values depend on your traffic and your backend.

The central trade-off: speed versus efficiency

Every batching choice balances two things. Freshness means how soon data appears in your dashboards. Efficiency means how cheaply the data is moved. A short timeout and small batch give fresher data but more requests. A long timeout and big batch give fewer requests but later data.

Read the Collector’s own numbers

The batch processor reports metrics about itself. Their names begin with the word otelcol followed by processor and batch. The exact names can vary by version, but the ideas are stable, and they tell you what is happening.

• How many batches were sent because of size, versus how many were sent because of the timeout.
• The sizes of the batches that were sent, both in item count and, in newer versions, in bytes.
• The number of separate metadata batches, if you use metadata keys.

flowchart TD
    S["Look at batch metrics"] --> Q1{"Are most sends caused by the timeout?"}
    Q1 -->|Yes| Q2{"Are batches much smaller than the size target?"}
    Q2 -->|Yes| A1["Traffic is low or timeout is short. Consider a longer timeout or smaller size target"]
    Q2 -->|No| A2["Settings look balanced"]
    Q1 -->|No| Q3{"Are most sends caused by the size trigger?"}
    Q3 -->|Yes| Q4{"Are batches exceeding backend message limits?"}
    Q4 -->|Yes| A3["Set or lower the max size"]
    Q4 -->|No| A4["Traffic is high and batching is efficient"]
    Q3 -->|No| A5["Check for traffic problems or missing data"]
    

A practical approach

Held data takes up memory, and memory is not unlimited.

Every item held in a batch uses memory. If your traffic suddenly jumps, many batches may hold a lot of data for a moment. The memory limiter processor is the Collector’s guard for this problem. It watches the Collector’s memory use, and when it gets near a limit, it starts refusing new data so the Collector does not crash. This is why it is placed before the batch processor.

Sizing the Collector

Add up the memory that batches could use at once, such as the batch size times the typical item size, times the number of pipelines, times any metadata batches. Then add the exporter queue. Compare it with the memory your container is allowed to use. If the numbers are close, either lower the sizes or raise the container limit.

Where you run the Collector affects how you batch.

flowchart LR
    A1["App with SDK batching"] --> AG1["Agent Collector with small batches"]
    A2["App with SDK batching"] --> AG2["Agent Collector with small batches"]
    AG1 --> GW["Gateway Collector with larger batches"]
    AG2 --> GW
    GW --> BE["Backend"]
    

Notice that batching can happen three times along the way: in the application’s SDK, in the agent Collector and in the gateway Collector. Each round has a different purpose. The first makes the trip from the app efficient. The second makes the trip to the gateway efficient. The last makes the final trip to the backend efficient. Do not worry about “double batching.” It is normal, as long as the total delay stays within what you can accept.

Honest accounting of what batching gives and what it costs.

Key trade-offs

Batching does not change what your data says, but it does change where data sits and for how long.

A pipeline that handles your monitoring data needs to be monitored too.

• Trigger mix: watch the share of sends caused by size versus timeout. A sudden change shows that traffic patterns have shifted.
• Batch sizes: track average and largest batch sizes. Very small ones waste efficiency, and very large ones risk rejection.
• Refused data: if the memory limiter is refusing data, the Collector is under pressure.
• Exporter failures and drops: watch for failed sends, retries, and dropped batches from full queues.
• Queue depth: an exporter queue that is always nearly full means the backend cannot keep up.
• Collector memory and CPU: check that these stay well below the container’s limits.
• Received versus sent counts: compare items received with items exported. A growing gap means loss somewhere in between.
• Collector logs: rejected-message errors from the backend often point to batches that are too large.

Common symptoms and likely causes

Habits worth copying and traps worth avoiding.

Good design patterns

Anti-patterns

A practical checklist for healthy batching.

Best practices

• Batch every networked pipeline. Traces, metrics and logs should all be grouped before leaving the Collector.
• Put batching last. After protection, shaping and sampling, and just before export.
• Start with defaults. Tune only after watching real behaviour.
• Set a max size. Keep messages safely below your backend’s limits.
• Pair with a memory limiter. Put it first, and size the container to match.
• Add up delays. Count the timeouts at every layer, from SDK to gateway.
• Keep metadata batching small. Use few keys with few values, and keep the limit on.
• Plan for restarts. Allow graceful shutdown and consider disk-backed queues if loss is costly.
• Monitor the batch metrics. Review trigger mix, batch sizes and drops regularly.
• Check release notes. The recommended place for batching has been changing, so confirm advice for your version.

Common mistakes beginners make

• Defining the batch processor but forgetting to list it in the pipeline.
• Believing the send size is a hard limit, when it is only a trigger.
• Forgetting that metrics are counted in data points, not in metric names.
• Putting the batch processor before sampling or filtering.
• Ignoring the combined delay of batching in several layers.
• Assuming “accepted by the Collector” means “stored in the backend”.
• Using unbounded metadata values and causing memory growth.

How batching shows up in tools and platforms you may already know.

A typical journey for a growing team

Quick answers to questions beginners ask most.

If you remember only a few things, remember these.