Deferred logging support

[mjwoolf]

Deferred logging support

Background

In production systems, it can be hard to debug intermittent issues. On the one hand, you want to have as much information as possible. On the other hand, excessive verbosity makes it hard to distinguish signal from noise and uses resources unnecessarily.

Deferred logging, also known as backtrace logging helps with this problem by adding certain log statements to a ring buffer and only outputting them if a certain condition is met in the future. This way, you can log what happened before something went wrong, without being spammed about cases where everything worked as intended.

Proposed API changes

We propose adding the following logging macros: LOG_DEFERRED, LOG_DEFERRED_IF, and VLOG_DEFERRED. They will behave like the corresponding undeferred macros, except instead of logging a given line, they will add it to a ring buffer.

We also propose adding the following functions:

namespace absl {

// Sets the maximum number of messages to keep in the deferred log ring buffer.
// Setting this to 0 (the default) disables deferred logging.
void SetDeferredLogBufferSize(size_t limit);

// Manually flushes all messages currently in the deferred log ring buffer
// to the registered LogSinks.
void FlushDeferredLogs();

enum class DeferredLogFlushMode {
  kFatalOnly, // Only flush deferred logs on LOG(FATAL).
  kErrorAndFatal // Flush deferred logs on both LOG(FATAL) and LOG(ERROR).
};

// Configure whether an ERROR or FATAL log should automatically trigger a flush.
// Default: kErrorAndFatal.
void SetFlushDeferredLogsOnError(DeferredLogFlushMode mode);

}  // namespace absl

Questions

1. Should we also expose flags to configure the ring buffer size and log flush mode?
2. Are the defaults above correct?
3. How should we handle logs with custom log sinks? What if the lifetime of the custom log sink is over before the deferred log is actually handled?

[derekmauro]

Thanks for the request and your interest in Abseil.

While we do hope that Abseil is useful to the C++ community at large, the library's primary function is to act as the stable foundation for Google’s codebase. Because Abseil is an open-source export of the code we use daily, our development is strictly driven by the requirements of Google-developed projects.

Unfortunately, this means we generally cannot accept feature requests for functionality that we don't currently need ourselves. Adding features without a Google-driven use-case creates a maintenance burden and compatibility issues that are difficult for us to justify. We appreciate your understanding of these constraints.

[mjwoolf]

Actually, I am a Googler. Is there a preferred way to suggest something like this internally?

[derekmauro]

Yes. I assumed you were not a Googler because GitHub isn't how we normally get these requests.

go/c-core-libraries-bug if you want to file a bug/feature request, or go/cpp-yaqs if you want to ask a question.