CASSGO-9 Add more logging, a Structured Logger interface and log levels #1755
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JIRA
Motivation
In my experience troubleshooting connection issues in gocql is quite complicated because there's not enough logging information available to understand what is going on under the hood (control connection reconnections, nodes being considered UP/DOWN, nodes being added or removed, connection pool errors, etc.). There is already some logging for this in place at the moment but it requires a build flag to be set which is far from ideal.
Adding logging for all of this by default would make the default gocql experience a bit frustrating for users that do not care about all of this extra information so log levels are also needed. With log levels, one can make the logging more verbose if they are trying to troubleshoot a particular issue. Other C* drivers already provide this kind of functionality out of the box.
Proposal
As mentioned in the prior section, with this PR I'm adding logging for a lot of the scenarios that were described above and I'm also adding log levels so that log verbosity can be tuned by users.
On top of the additional logging and log levels, I'm also adding better support for structured logging (new
StructuredLogger
interface and field in the cluster config). Note that the current "printf" way needs to be supported at the very least until gocql v2 to maintain the same behavior that exists today in apps that are leveraging theStdLogger
interface.I'm proposing to set the default log level as
WARNING
because it looks likeWARNING
is the most appropriate default level taking into account what logging there is today in gocql by default (prior to this proposal).It would be great if other community members could chime in on this proposal to improve any weak points that it might have and to make sure it addresses the needs of our users.
Usage/Examples
Example application side code with zerolog:
Alternatives
I considered
log/slog
instead of creating a new Structured Logger interface from scratch butlog/slog
was only introduced ingo 1.21
so I discarded this option for now. Maybe it would be a good idea to move tolog/slog
down the line when a new major version of gocql is being worked on?Drawbacks
The biggest drawback in this solution is that in order for a user to take full advantage of the new StructuredLogger interface, they have to implement a new type while this wasn't needed in the case of
StdLogger
for some logging libraries.I've added 2 new "extension" modules to provide an out of the box implementation of this new logger interface with
zerolog
andzap
but I'm not sure if this would be the best approach to provide this functionality.Log output examples
The following examples were collected following one simple procedure with CCM where:
Each log sample was collected on a unique run of this procedure so these log samples might not be fully comparable with each other.
Zerolog with gocql minimum log level set to WARN
Default logger with gocql minimum log level set to WARN
Zerolog with gocql minimum log level set to DEBUG
Default logger with gocql minimum log level set to DEBUG