Skip to main content
This guide shows how to configure a processor in the OpenTelemetry Collector to change how telemetry is exported. We’ll focus on the batch processor to reduce exporter load and network chattiness by grouping items and flushing them on a timeout or when a batch size threshold is reached. Why this matters
  • By default, each telemetry signal (traces, metrics, logs) is forwarded to exporters immediately when received.
  • High-volume telemetry can create excessive network traffic or overwhelm an exporter.
  • The Collector can batch, filter, modify, or sample telemetry between receivers and exporters using processors.
Processors operate between receivers and exporters. They can modify, filter, sample, or batch telemetry before it is sent to exporters.
What processors do
  • Receive data from a receiver.
  • Modify, enrich, filter, sample, aggregate, or batch that data.
  • Forward the processed data to configured exporter(s).
Example: current (simple) service pipelines configuration
Common processors and when to use them Below are some processors the Collector supports. Multiple processors can be applied to a single pipeline and will execute in series (processor 1 -> processor 2 -> …).
ProcessorUse caseExample / notes
attributesEnrich, remove, or mask attributes on telemetrySee the attributes example below for insert, update, delete, hash actions.
batchBuffer telemetry and flush on timeout or batch sizeUseful to reduce exporter load and network chatter.
filterKeep or drop telemetry based on expressionsFine-grained filtering for traces, metrics, logs.
Processors run in the order listed in a pipeline; the output of one processor becomes the input of the next. Attributes processor (example actions)
Filter processor (example usage)
Batch processor: behavior and configuration The batch processor buffers telemetry and will flush the buffer when either:
  • A timeout elapses (e.g., 15s), or
  • A configured send_batch_size is reached (e.g., 512 items).
This protects exporters from bursts and reduces chattiness, but it can introduce buffering latency. Minimal Receiver + Batch configuration
Add a batch size threshold
Explanation
  • timeout: 15s — flush at most every 15 seconds (since first item in the batch).
  • send_batch_size: 512 — flush sooner if the batch reaches 512 items.
  • The buffer flushes when either condition is met (whichever happens first).
Important: batching increases latency for individual telemetry items; tune timeout and send_batch_size to balance latency and throughput.
Batches reduce exporter load but introduce buffering delay. If you need near-real-time telemetry, set lower timeouts or avoid batching for that pipeline.
Enabling processors in service pipelines After defining processors under processors:, reference them in the service.pipelines section where you want them applied. Processors listed for a pipeline execute sequentially. Example: enabling batch for traces
Multiple processors
  • When multiple processors are specified, they run in series: receiver -> processor A -> processor B -> exporter(s)
Generate telemetry to compare behaviors First, observe behavior without the batch processor (immediate export). Using telemetrygen to generate traces and logs:
Sample output you might see when exporters are writing immediately (debug exporter prints to console):
With no batch processor enabled, traces and logs are forwarded and printed immediately. Enable the batch processor Example configuration that enables batching for traces and sends to Jaeger:
Behavior with batch enabled
  • If you generate three traces and the batch timeout is 15s, they will be buffered and will not reach exporters (or appear in the debug console) until:
    • 15 seconds have elapsed since the first item in the batch, or
    • 512 items have been collected.
  • Collector logs will show the receiver starting and the service becoming ready; after the timeout elapses the buffer is flushed and you’ll see debug exporter output.
Collector log sample (startup and flush)
Summary
  • Processors let you inspect, modify, filter, sample, or batch telemetry between receivers and exporters.
  • The batch processor reduces exporter load and network chatter by grouping telemetry and flushing on a timeout or size threshold.
  • Add processors to specific pipelines to apply them per-signal; multiple processors run sequentially.
  • Tune timeout and send_batch_size to balance latency and throughput for your environment.
Links and references

Watch Video