Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix log level handling #93

Merged
merged 6 commits into from
May 26, 2020
Merged

Fix log level handling #93

merged 6 commits into from
May 26, 2020

Conversation

Stebalien
Copy link
Member

Currently, we filter messages at two layers:

  1. At individual subsystem loggers.
  2. At the final logging core.

However, the final log level was set to ERROR. That meant that reducing the level on subsystem loggers didn't actually do anything. This meant SetLogLevel didn't work. This change sets the default log level for pipe readers and the default logging core to DEBUG.

This change also changes the default pipe reader format to JSON to avoid taking a lock. IMO, this should be less surprising regardless as it's more predictable.

I'm not entirely happy about how we're handing log levels but this should be good enough for now. Ideally, we'd have #92.

This seems like the most reasonable default. We no longer need to take a lock to
read the global log level, so we might as well drop the lock entirely.
That way, the reader gets a nice EOF instead of a "read on closed pipe" error.
This shouldn't be necessary, but it can't hurt.
@Stebalien
Copy link
Member Author

cc @iand

setup.go Outdated
// primaryFormat is the default format of the primary core used for logging
var primaryFormat LogFormat = ColorizedOutput
// defaultFormat is the default format of the primary core used for logging
var defaultFormat LogFormat = ColorizedOutput
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally named them primaryFormat/primaryLevel because they correspond to the format and level used by the primary core which. It's not really a default

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

primaryFormat makes sense. primaryLevel isn't quite correct because the level for the primary logger needs to be debug.

pipe.go Outdated
// By default, it:
//
// 1. Logs JSON.
// 2. Logs at the Debug level. However, unless SetLogLevel is called on a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to set it to be the same as the primary logger's level by default. The user will then see the same logs that are being logged to stderr or the output file. They still have an option to inspect debug messages from subsystems that have had their log level decreased.

Either way the comment about "only error messages will be logged" is slightly confusing because if they have specified GOLOG_LOG_LEVEL=Info then the primary core will be emitting log events at that level and above.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to set it to be the same as the primary logger's level by default.

It is. The primary log level is debug and must be debug. Otherwise, calling SetLogLevel("some-subsystem", "debug") won't work because, while the messages will make it through the subsystem's logger, they'll get stopped by the primary logger because the primary logger will still filter out all messages with levels below ERROR.

(but I agree that the comment is really confusing)

@Stebalien Stebalien merged commit 9a85138 into master May 26, 2020
@Stebalien
Copy link
Member Author

Thanks for the review!

@Stebalien Stebalien deleted the fix/log-level branch May 26, 2020 22:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants