OTLP exporter sending_queue drops telemetry during downstream connection pool exhaustion instead of propagating backpressure

Short answer

In current OpenTelemetry Collector releases, a saturated sending_queue drops telemetry by default (on_overflow: drop); silent loss is the designed failure mode. The only configuration that can make the exporter signal upstream receivers to slow down is sending_queue.on_overflow: block, and only in builds where that value exists. With it, a full queue blocks the exporter's consume path, which over OTLP/gRPC can propagate backpressure to upstream clients through gRPC flow control; over OTLP/HTTP the propagation is much weaker, reaching upstream only via socket buffers and client timeouts. There is no widely established first-class internal metric that reliably separates downstream connection-pool saturation from local queue overflow — exporter metrics generally expose queue size/capacity and send-failure counters, not pool wait counts.

Confirmed behavior vs. version-dependent details

Confirmed across current documentation: the bounded queue defaults to dropping on overflow, and raising queue_size, num_consumers, timeout, or enabling retry_on_failure only changes local buffering and retry behavior — it does not signal upstream receivers to slow down. Version-dependent and worth verifying against your installed build: whether on_overflow: block is accepted, the exact names of the queue size/capacity and send-failure metrics, and the gRPC vs HTTP connection-pool defaults. Do not assume block exists or is the default in your release.

Configuration changes for this case

1. Inspect the exporter's sending_queue block: if on_overflow is absent, that build is drop-only on overflow.
2. If supported, set on_overflow: block so a full queue stalls the exporter instead of dropping. Expect the failure mode to shift from dropped telemetry to blocked receivers — upstream latency, client timeouts, or pipeline stalls are the trade-off.
3. Size the queue and consumers to absorb transient pool exhaustion (queue_size, num_consumers, timeout, retry_on_failure) as buffering, not as backpressure.
4. For OTLP/gRPC exporters, review channel and keepalive settings; for OTLP/HTTP, review the HTTP transport limits (Go http.Client transport, MaxIdleConns/MaxConnsPerHost-style settings). Defaults and exhaustion symptoms differ by protocol and Collector version.

Metrics: pool saturation vs. queue overflow

No reliable first-class metric isolates downstream pool saturation. In practice you correlate exporter queue size/capacity metrics (names are version-sensitive — confirm against your build) with send-failure counters and downstream errors. Pool exhaustion typically surfaces as generic Unavailable/connection errors and can look identical to queue overflow in logs; distinguishing them requires version-specific instrumentation or reproducing the exhaustion while watching the queue metrics under load.

Verification

• Expose the Collector's metrics endpoint and watch exporter queue size/capacity and send-failure counters during a load test.
• Reproduce downstream pool exhaustion and observe whether upstream OTLP clients see gRPC flow-control stalls (backpressure propagated) or only HTTP latency growth (weak propagation).
• Consult the installed version's release notes and config reference for on_overflow support and gRPC vs HTTP pool defaults.

One diagnostic detail would change this recommendation: the exact Collector version and distribution you run, since on_overflow support, metric names, and pool defaults are all release-sensitive.