Define OpenTelemetry Collector loss boundaries before increasing queues

Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.

Source facts

OpenTelemetry Collector resiliency guidance describes sending queues, retries, and optional persistent storage. An in-memory queue can drop incoming data when full; retry-duration exhaustion can also discard data. Persistent storage through file_storage can retain queued items across Collector restart, but disk failure, exhausted space, and other limits remain potential loss paths.

Source: OpenTelemetry documentation — Resiliency.

Applicability

Review Collector exporter queue, retry and persistent-storage loss boundaries in the resiliency guidance.

DSE recommendation

DSE recommends defining acceptable telemetry loss and expected destination outage duration before choosing queue and retry settings. Account for arrival rate, memory or disk capacity, and catch-up throughput. Give persistent storage its own monitoring and recovery owner. Separate endpoint failure from backend overload; a larger queue can defer a problem without fixing it. Keep important audit or business records on a delivery system whose guarantees match their requirement rather than relying on an unspecified telemetry buffer.

Verification

In an isolated pipeline, interrupt a test destination and observe queue growth, retries, recovery, and any loss indicators. Restart a Collector containing disposable queued data to validate the chosen storage behavior. Confirm disk-space and retry-limit alerts are useful before applying the configuration to production telemetry. Retain sample identifiers and the exporter queue state across the interruption. Have the pipeline owner reconcile received and missing test items and approve the tested outage boundary before increasing the queue in production.

Official reference

OpenTelemetry documentation — Resiliency. Reviewed October 20, 2026.