Search papers, labs, and topics across Lattice.
This study investigates the limitations of Docker's Logs API in achieving exact recovery of missed records during collector downtime or lifecycle changes. By defining the concept of source-bounded exactness, the authors demonstrate that merely retaining a read position is insufficient for recovery, revealing that lifecycle reacquisition plays a critical role in ensuring that all distinguishable source records are accurately captured. The findings indicate that their method, LogDeck, outperformed the unmodified Grafana Alloy in exact recovery, achieving success in all trials compared to Alloy's significantly lower success rate.
Lifecycle reacquisition, not just persisted read positions, is the key to achieving exact recovery of Docker logs, as shown by LogDeck's perfect performance against Alloy's failures.
Docker can retain records that a collector misses before attachment or during downtime. A persisted read position does not by itself ensure recovery after lifecycle changes. We study what exact recovery contract is achievable through Docker's supported Logs API. We define source-bounded exactness: every retained, distinguishable source record eventually appears exactly once in durable collector output. Our method uses a generation-aware multiset oracle that separates source truncation from collector omission and exposes simultaneous loss and replay. Applied to LogDeck, it uncovered a start-to-attachment race; a one-record attachment overlap, finite Docker-API reconciliation, and exact insertion closed the tested boundary. We compare the fixed revision with unmodified Grafana Alloy 1.18.0, which uses the same API and persists read positions; across 120 collector-runs, LogDeck was exact in 60/60 and Alloy in 20/60. Alloy succeeded at guarded startup and process pause but omitted retained history when recovery required discovering an exited or restarted source. In a causal control, a 5,000-record source exited before collection: stock discovery was exact in 0/20 trials and acquired nothing, while the same reader given the container ID recovered all records exactly in 20/20. This reproduced on OrbStack and independent Ubuntu hosts with Docker 29.4.0 and 24.0.9; both collectors recovered daemon restart, while neither recovered records after source removal. Exactness assumes distinct tuples of physical generation, timestamp, stream, and bytes; 200,000 byte-identical records across two drivers produced no observed collisions. Our results show that lifecycle reacquisition, not a persisted position alone, determines exact recovery within the retained-source horizon. This is a bounded interface claim, not a universal collector ranking or proof of collision freedom.
