Dllog

The core concept of Dllog is to avoid writing detailed logs under normal circumstances, and only replay the full debug log when an operation fails.

During operation execution, Dllog temporarily stores debug-level logs in an in-memory buffer rather than immediately writing them to persistent storage.

Dllog is an early-stage project just published on Hacker News in a 'Show HN' format, having only single-digit votes and no comment discussion at the time of posting.

The difference between Dllog and tail-based sampling is that Dllog pushes the deferred persistence decision mechanism down to the single-process logging level, requiring no distributed collection infrastructure.

Dllog is best suited for scenarios where operations succeed most of the time and fail only occasionally, since the vast majority of debug logs will be discarded.

Dllog's debug logs need to reside in memory throughout an operation, which may create memory pressure for long-running operations or those that generate a large volume of logs.

For problems such as gradual performance degradation or intermittent anomalies that do not manifest as a clear failure of a single operation, Dllog's fail-then-replay model may miss important clues.

For nested operations where a sub-operation fails but the parent operation catches the error and continues running, Dllog may exhibit a silent failure risk where the failure is swallowed and the logs are discarded along with it.

Using Dllog requires developers to explicitly define what constitutes a failure and to handle different cases such as exceptions, timeouts, and business logic errors.