SimpleSpanProcessor

What SimpleSpanProcessor Does

SimpleSpanProcessor is the most direct OpenTelemetry span-processing mode: when a span ends, it is exported immediately on the application thread. That makes the telemetry path easy to reason about and useful for short-lived or low-volume workloads, but it also means exporter behaviour is part of the request path rather than a background concern.

Why Its Synchronous Design Matters

The key design choice is synchronous export. Each completed span waits for the exporter call to finish, so the processor gives immediate delivery semantics at the cost of coupling observability to application latency. In practice, that coupling is acceptable when the exporter is fast and reliable, and less suitable when spans are frequent or the telemetry backend can stall.

This is why the term matters operationally: the processor does not just format telemetry, it changes how the application experiences backpressure, timeout behaviour, and failure sensitivity in the instrumentation path.

Performance and Reliability Trade-offs

Because export happens inline, a slow collector, network interruption, or blocked sink can increase response times for the code emitting spans. The effect is often small in development or lightweight services, but in production the overhead can become visible when request rates rise or when tracing is enabled broadly across latency-sensitive paths.

SimpleSpanProcessor is also less forgiving than asynchronous buffering models. If the exporter cannot keep up, the application can spend more time waiting on telemetry work, which can reduce throughput and make tracing itself part of the performance budget.

When to Use It

SimpleSpanProcessor fits best when immediate export is more valuable than efficiency, such as in testing, demos, short-lived jobs, or environments where trace volume is low and exporter reliability is high. It is also a practical choice when you want the clearest possible delivery semantics during early development or troubleshooting.

For sustained production traffic, teams usually prefer a batched approach unless they have deliberately chosen the latency trade-off. The important judgement is not whether tracing is enabled, but whether synchronous delivery belongs on the critical path of the workload being instrumented.

Risk and Threat Considerations

The main risk is availability and latency impact, not data confidentiality. If the exporter or downstream telemetry service slows down, the application can inherit that delay directly, which makes observability infrastructure a dependency of request performance.

Failure mechanism: each finished span waits for immediate export, so exporter slowness, retries, or transient unavailability can amplify application latency and reduce throughput.

Impact: tracing can become a source of user-visible slowdown, and in extreme cases it can contribute to cascading performance degradation during incidents or backend outages.

Practitioner Guidance

What to watch for: treat this processor as a deliberate trade-off, not a default setting. It is appropriate when trace volume is modest and synchronous delivery is acceptable, but it should be reviewed carefully in request-driven services where latency headroom is limited.

Practitioner takeaway: if trace emission must never affect the critical path, prefer a buffered export model and reserve SimpleSpanProcessor for situations where immediate span delivery is the explicit requirement.