-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Make it possible to extract fields from the context in the slog adapter #1372
base: master
Are you sure you want to change the base?
Conversation
Since slog has context logging built in it would be nice to be able to utilize that with a zap handler, for example to log tracing context.
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 makes sense to me! I think the name WithFieldsFromContext is a bit more descriptive than WithContextExtractor.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1372 +/- ##
==========================================
+ Coverage 98.28% 98.43% +0.14%
==========================================
Files 53 53
Lines 3493 3505 +12
==========================================
+ Hits 3433 3450 +17
+ Misses 50 46 -4
+ Partials 10 9 -1 ☔ View full report in Codecov by Sentry. |
I can change it to that, but do you then have any suggestion for the field/type name? |
My apologies, I've thought about it some more and looked at more code and propose a modification to WithContextFieldExtractors(extractors ...ContextFieldExtractor), where a ContextFieldExtractor takes a context.Context and returns a single zapcore.Field. I think this will make composing and sharing logic between multiple extractors a bit easier than if the option constructor took in a single extractor function that returned multiple fields. What do you think? |
Sorry for the late reply - we could do that instead, but it will lead to some amount of duplicated work. My specific use case is to add tracing info to logs, and for that I have something like this:
Splitting that into 3 extractors instead then requires me to get the span context 3 times, check if it's valid, and then emit single fields. How about instead allowing multiple extractors, but allow them to still return a slice of fields? |
Sorry for the delay, I will follow up here by Weds! |
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.
Makes sense to me.
Providing options for multiple extractors that can provide multiple fields seems adaptable to both cases where someone might want to re-use context extractors or provide a single one for all of their fields.
Will approve after CI passes.
Since slog has context logging built in it would be nice to be able to utilize that with a zap handler, for example to log tracing context.