Observe each queue boundary
The logger has a bounded queue with default capacity 1024. A saturated logger queue drops records and reports pressure through get_dropped() and rate-limited warnings. Handler capacities are independently configurable through builders; 1024 is not a universal maximum.
File policies are drop, block, or timeout. A blocking handler policy can stall dispatch and cause pressure upstream. It does not make the logger queue durable. Monitor both logger drops and handler diagnostics.
Stop producers before draining
- Stop new logging calls.
- Wait for any application-specific delivery acknowledgement when Python callbacks or handlers are involved.
- Call
flush_handlers()on the logger, then on ancestor loggers that own output. Check each boolean result. - Detach and close explicitly owned handlers. Release configured native handler references only after the queues drain.
Source verification at revision f5bcaa8 found that an immediate logger flush can time out while a queued Python handler waits for the GIL. The worked examples wait on an Event set during delivery before flushing. A sleep of arbitrary duration is not a delivery acknowledgement.
Logger drain has a two-second bound. Stream flush defaults to one second and returns False for failure, closure, a disconnected worker, or timeout. Successful flush is not a promise of durable storage beyond the underlying I/O contract.
Investigate missing output
- Check effective levels, filters, propagation, and attached handlers.
- Check logger drops and worker warnings before increasing capacity.
- Check permissions, disk state, frame sizes, credentials, and endpoint reachability.
- Check every flush result and keep the process alive long enough for bounded close.
HTTP close can abandon an unresponsive worker after the write timeout. Queued requests may complete only if the process continues running. Avoid shutdown paths that assume all network records have arrived.
Keep destinations explicit
Secrets, access tokens, personal data, stack traces, and source paths need review before network output. Journald and OpenTelemetry exporters are planned integrations; Rust log/tracing bridges do not imply those exporters exist.