-
Notifications
You must be signed in to change notification settings - Fork 34
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
Slog writer #46
base: master
Are you sure you want to change the base?
Slog writer #46
Conversation
To take advantage of the new logging package from the go 1.21 release, the loggo package starts incorporate these new changes. There are features that we could start to add to loggo to then pass directly to slog. The migration over to slog could then be done in stages. For now, it might be useful to at least play around with slog and see if there are any advantages to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM,
How do you think this could work with our filtering logic for logs from the client? Do you see a path forward that would allow us to use slog interface directly over loggo ?
Tests would be good as well.
case loggo.CRITICAL: | ||
return slog.LevelError + 1 | ||
default: | ||
panic("unknown level") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only part I am a bit iffy about. Don't feel comfortable that there exists a case in a library where we can blow up. Can we just default off to a sane log level?
I know it's a low chance...
b86c0f7
to
022df51
Compare
In order to correctly interface with the log/slog package and to take advantage of structured logging, we now introduce attributes. Currently Info and Infof are different, in the fact that Info is the structured variation. It expects every argument to be a attribute after the initial message string. This then allows us to have a slog backend without migrating away from loggo directly. We have all the benefits of loggo plus we can take advantage of the new logging infra.
022df51
to
c49e5da
Compare
To take advantage of the new logging package from the go 1.21 release, the loggo package starts incorporate these new changes. There are features that we could start to add to loggo to then pass directly to slog. The migration over to slog could then be done in stages.
For now, it might be useful to at least play around with slog and see if there are any advantages to it.
Running the new example, we can take advantage of slog for the backend with structured logging.
This still works with namespacing as well.
Notice that first is at trace and everything else is at warning.