Choose Docker non-blocking logging with an explicit loss budget

Avoiding log backpressure trades a stalled writer for possible missing records.

Source facts

Docker supports blocking delivery from a container to its logging driver and non-blocking delivery through an intermediate per-container buffer. Non-blocking mode prevents the application’s log writes from waiting on the driver. When that buffer is full, new messages are not enqueued and are dropped. Buffering therefore changes the failure mode rather than guaranteeing delivery.

Source: Docker documentation — Configure logging drivers.

Applicability

Review Docker’s container-to-driver delivery mode and the behavior of its intermediate buffer.

DSE recommendation

DSE recommends deciding which is more damaging for the workload: delayed application writes or loss of diagnostic records. Record that decision with the service owner before changing delivery mode. Size and monitor buffering from observed log volume and outage expectations rather than an arbitrary large value. Separate essential business records from best-effort diagnostic output when those records require stronger delivery guarantees. Include the downstream driver and collector in the review so increasing one buffer does not conceal an unresolved export bottleneck.

Verification

In a disposable environment, simulate a slow or unavailable log destination while observing application responsiveness and message continuity. Verify that the selected mode produces the accepted behavior. Confirm operational monitoring can identify sustained logging trouble without relying only on messages that may themselves be dropped. Use numbered benign records to reconcile generation and receipt across the interruption. Have the service owner sign off the observed responsiveness and missing-record result against the chosen tradeoff, including the monitoring path used to detect trouble.

Official reference

Docker documentation — Configure logging drivers. Reviewed October 20, 2026.