Compare the simple and batching span processors in the OpenTelemetry SDK. What do the queue size, schedule delay, maximum export batch size and export timeout settings control, what happens when the queue fills, and what must a short-lived process do before exiting?

## Where processors sit Span creation → sampler decision → the span runs → span end → **span processor** → exporter → the wire. The processor's job is to decouple the application from the exporter's latency and failure modes. ## Simple processor On every span end, export immediately and synchronously. Its virtue is zero delay and zero buffering: what ends is on the wire. Its vice is that the thread that finished your request now waits on a network call, and every span costs one request. Use it with a console exporter while debugging, or in tests where determinism beats throughput. It is not a production configuration. ## Batching processor Ended spans go onto a bounded queue; a background worker drains them into batches and calls the exporter. The four settings interact: - **Max queue size** — how many ended spans may wait. This is your memory bound: queue size × average span footprint. Raising it buys tolerance for bursts and backend hiccups, and costs heap. - **Schedule delay** — the maximum time a span waits before the worker exports what it has. Lowering it reduces the lag between an event happening and being visible, at the cost of smaller, more frequent requests. - **Max export batch size** — the ceiling on one export request. Bounds payload size and per-request latency; a batch this large triggers an export before the timer fires. - **Export timeout** — how long one export attempt may take before being abandoned. Too generous and a stalled backend blocks the worker while the queue fills behind it. ## The drop behaviour, and why it is right If the queue is full when a span ends, the span is discarded. The alternative — blocking the application thread until space frees — would let a slow or unreachable backend degrade the very service you are observing. Telemetry must fail before the application does. The cost is that loss is **silent**: the trace simply has holes, or entire traces vanish, with no error in your logs. This is why SDK self-diagnostics matter. SDKs expose their own metrics for queued and dropped spans and for export failures; those should be on a dashboard, because 'my traces are incomplete' is otherwise indistinguishable from a sampling or instrumentation problem. The common root causes are a genuinely slow backend, an export timeout too large relative to the schedule delay, or a burst far beyond the queue size. ## Interaction with sampling Spans that the sampler dropped never reach the export path, and record-only spans are recorded but not exported. So the processor is sized for the *sampled* volume, not the total. If you change the sampling rate, the batching settings need revisiting — a tenfold increase in kept spans against an unchanged queue means drops. ## Shutdown, flush and short-lived processes Batching implies that at any moment some spans exist only in memory. Two operations matter: - **force flush** — export everything queued now and wait for completion. - **shutdown** — flush and then release the exporter, after which the processor accepts nothing more. A long-running server should hook shutdown into its termination path so the final seconds of telemetry survive a rolling deploy. A **short-lived process** — a CLI, a batch job, a serverless invocation — is far more exposed: it can easily die with its entire telemetry still in the queue, so it must force-flush before exit. In freeze-the-process execution environments the flush must additionally happen before the runtime is suspended, not in a background thread that is never scheduled again. Where flush latency per invocation is unacceptable, the usual answer is to export to a local collector instead so the handoff is cheap and durability moves out of the process. ## The sibling mechanisms Metrics do not use span processors. They use a **metric reader**, typically a periodic exporting reader on its own interval (`OTEL_METRIC_EXPORT_INTERVAL`, commonly 60s), because metrics are aggregated state read on a cadence rather than a stream of finished items. Logs mirror traces with their own batching log-record processor and its own `OTEL_BLRP_*` variables. Same shape, separate knobs — do not assume tuning one signal tuned the others.