The Stacks Core node currently has two log modes; default (for lack of a better term) and debug. Default logging often shows RPC server and block processing activity, while debug mode prints just about all log lines in the code base.
When running a follower node as an RPC server or just to participate, default logging is often the right amount of logs needed. When developing or debugging, turning on debug mode often leads to a generated log volume that is several magnitudes larger than what is needed.
For example, the below screenshot shows almost half a TB of debug-level logs were generated by just a few stacks nodes over 1 hour:
Not only is this unwieldy and costly for most log-ingestion systems, but often times it's more than what's needed and the value extracted from printing so many logs has diminishing returns except in few cases. It makes debugging issues challenging with any logging system or when using log files.
Proposal
With component scoped debug logging, you'd be able to target the components in the source code which should print debug logs, while any other components not mentioned would print at the default log level. For comparison, Bitcoin Core has this in their code base and it's made debugging issues in bitcoin nodes tremendously helpful. These are all the configurable debug logging modes:
https://github.com/bitcoin/bitcoin/blob/master/src/logging.cpp#L170-L202
In addition to this, it's possible to enable debug logging for all components.
This could be implemented for the Stacks Core node in a similar way, by a configurable property in the config.toml or env var. Ideally it would accept a list of values, where each value is a named component in which debug logging would be turned "on", while other components not mentioned will print default logs. And the component "all" would simply result in the same behavior as turning on debug logging today.
Having something like this in the Stacks Core node would allow developers to enable debug logs in only the components they're working on or otherwise care about, thus making it easier to search through logs and debug issues quicker than today. Additionally, it would help reduce the stress on log collection systems and the cost of maintaining them or any logs captured.
Problem
The Stacks Core node currently has two log modes; default (for lack of a better term) and debug. Default logging often shows RPC server and block processing activity, while debug mode prints just about all log lines in the code base.
When running a follower node as an RPC server or just to participate, default logging is often the right amount of logs needed. When developing or debugging, turning on debug mode often leads to a generated log volume that is several magnitudes larger than what is needed.
For example, the below screenshot shows almost half a TB of debug-level logs were generated by just a few stacks nodes over 1 hour:
Not only is this unwieldy and costly for most log-ingestion systems, but often times it's more than what's needed and the value extracted from printing so many logs has diminishing returns except in few cases. It makes debugging issues challenging with any logging system or when using log files.
Proposal
With component scoped debug logging, you'd be able to target the components in the source code which should print debug logs, while any other components not mentioned would print at the default log level. For comparison, Bitcoin Core has this in their code base and it's made debugging issues in bitcoin nodes tremendously helpful. These are all the configurable debug logging modes: https://github.com/bitcoin/bitcoin/blob/master/src/logging.cpp#L170-L202
In addition to this, it's possible to enable debug logging for all components.
This could be implemented for the Stacks Core node in a similar way, by a configurable property in the config.toml or env var. Ideally it would accept a list of values, where each value is a named component in which debug logging would be turned "on", while other components not mentioned will print default logs. And the component "all" would simply result in the same behavior as turning on debug logging today.
Having something like this in the Stacks Core node would allow developers to enable debug logs in only the components they're working on or otherwise care about, thus making it easier to search through logs and debug issues quicker than today. Additionally, it would help reduce the stress on log collection systems and the cost of maintaining them or any logs captured.