Skip to main content
Span processors are hooks invoked when a span starts and ends. They are responsible for batching, filtering, and exporting spans to backends.

SpanProcessor Interface

From opentelemetry-sdk/src/trace/span_processor.rs:74-136:

Built-in Processors

OpenTelemetry SDK provides two main span processors:

SimpleSpanProcessor

Exports spans synchronously as soon as they end (defined in opentelemetry-sdk/src/trace/span_processor.rs:138-212). Use cases:
  • Debugging and testing
  • Low-throughput applications
  • When you need immediate export
Characteristics:
  • Exports each span individually
  • Blocks the thread that ends the span
  • No batching overhead
  • Higher export overhead per span

Exporter Compatibility

When using OTLP exporters with SimpleSpanProcessor:
  • grpc-tonic - Requires TracerProvider created within a tokio runtime. Spans can be emitted from any thread.
  • reqwest-blocking-client - TracerProvider may be created anywhere, but spans must be emitted from non-tokio threads.
  • reqwest-client - TracerProvider may be created anywhere, but spans must be emitted from tokio runtime threads.

BatchSpanProcessor

Collects finished spans and exports them in batches (defined in opentelemetry-sdk/src/trace/span_processor.rs:214-300). Use cases:
  • Production applications
  • High-throughput scenarios
  • When minimizing export overhead is important
Characteristics:
  • Uses a dedicated background thread
  • Batches spans before export
  • Configurable queue and batch sizes
  • Scheduled periodic exports
  • Lower per-span overhead

Exporter Compatibility

When using OTLP exporters with BatchSpanProcessor:
  • grpc-tonic - Requires TracerProvider created within a tokio runtime
  • reqwest-blocking-client - Works with regular main or tokio::main
  • reqwest-client and hyper - Not supported with BatchSpanProcessor

Batch Configuration

Customize BatchSpanProcessor behavior:

BatchConfig Options

From opentelemetry-sdk/src/trace/span_processor.rs:52-72:

Configuring Batch Processor

Environment Variables

Configure batch processor via environment variables:

Complete Example

From the documentation in opentelemetry-sdk/src/trace/span_processor.rs:227-272:

Custom Span Processors

Implement custom processing logic:

Filtering Processor

Filter spans before export:

Multiple Processors

Register multiple processors for different purposes:
Processors are invoked in the order they were registered.

Context in Processors

Critical: Do not use Context::current() in on_end. It returns an unrelated context.
From opentelemetry-sdk/src/trace/span_processor.rs:87-118:

Shutdown and Force Flush

Graceful Shutdown

Always shutdown the provider before application exit:

Force Flush

Flush pending spans without shutting down:

Best Practices

BatchSpanProcessor minimizes export overhead and prevents blocking application threads. Use SimpleSpanProcessor only for debugging.
Balance between memory usage (queue size) and export frequency. Larger batches reduce overhead but increase memory usage and latency.
Call shutdown() before application exit to ensure all spans are exported. Use sufficient timeout for batch processors to flush.
Never rely on Context::current() in on_end. Extract needed information in on_start and store as span attributes.
In high-throughput scenarios, monitor dropped span counts. Increase max_queue_size if spans are being dropped.

Tuning for High Throughput

For applications generating many spans:

Complete Production Example

Next Steps

Sampling

Control which spans are recorded

Overview

Return to tracing overview