Survive backend outages with a persistent queue

The file_storage directory must exist and be writable before startup (create_directory: true handles first boot, but on Kubernetes you still need a PVC or hostPath mount; an emptyDir volume is wiped on pod rescheduling, which defeats the whole point).

With max_elapsed_time: 0 nothing is ever aged out of the queue, so a long outage grows the bbolt file until the volume fills; size the volume for your outage budget and alert on the collector's own otelcol_exporter_queue_size metric.

bbolt never returns disk space by itself; without compaction.on_rebound and on_start the database file stays at its post-outage high-water mark forever.

This is backpressure, not zero loss: once the disk queue fills, block_on_overflow and memory_limiter push refusal back to the SDKs, and whether data survives from there depends on SDK-side retry and buffering; the OTel resiliency docs are explicit that these mechanisms reduce rather than eliminate loss.

Use the otlp_grpc exporter id, not otlp: core v0.144.0 renamed the exporter and the old id is a deprecated alias. Also note that setting sending_queue::storage removes the in-memory queue entirely, so queue throughput becomes disk-bound; leave fsync off unless you need integrity over throughput.