OpenTelemetry Collector and backend data consistency during restoration events

Direct answer

The OpenTelemetry Collector does not prevent duplicate metrics after a backend restoration. It retries batches under at-least-once semantics and has no configuration to verify that a restored dataset matches the original OTLP export history.

Confirmed behavior versus likely outcomes

Confirmed: the collector is a stateless proxy. It does not keep a persistent ledger of acknowledged spans or metrics across restarts. When an export fails, it retries until the backend returns success. If the backend is restored to a snapshot taken before those successful exports, the collector has no signal that the backend state has regressed.

Likely: any batch acknowledged just before the snapshot cutoff but still present in a persistent queue—or replayed after a collector restart—will be exported again. This creates duplicates. The exact window depends on queue persistence, retry timing, and snapshot boundaries, so treat it as deployment-specific.

Steps for this case

1. Review the exporter's retry_on_failure and sending_queue settings. Persistent queues increase replay risk after a collector restart; reducing or disabling persistence shrinks the duplicate window but does not eliminate it.
2. Check whether your storage backend supports idempotent inserts keyed on OTLP identifiers such as trace IDs, span IDs, or timestamps. If it does, duplicate exports can be collapsed at write time.
3. If the backend lacks idempotent writes, plan a post-restore reconciliation job that compares row counts or checksums against a known export window. The collector cannot perform this validation.

Version assumptions and verification

Assume a recent stable collector release. Exporter defaults and queue behavior change across versions, so verify current retry_on_failure and sending_queue documentation for your build before relying on any specific timeout or capacity value.

One diagnostic detail that changes the recommendation

If you can confirm whether your backend supports idempotent inserts keyed on OTLP resource and span IDs, the mitigation shifts from tuning collector queues to enabling backend-side deduplication or scheduling a reconciliation step.