-
Notifications
You must be signed in to change notification settings - Fork 702
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
logging: add AddFields #739
logging: add AddFields #739
Conversation
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.
Could you clarify the difference between AddFields
and InjectFields
?
Support the similar helpers from the v1 introduced in grpc-ecosystem#91: - [ctxzap.AddFields](https://github.com/grpc-ecosystem/go-grpc-middleware/blob/v1/logging/zap/ctxzap/context.go#L23-L32) - [ctxlogrus.AddFields](https://github.com/grpc-ecosystem/go-grpc-middleware/blob/v1/logging/logrus/ctxlogrus/context.go#L22-L30) - [ctxkit.AddFields](https://github.com/grpc-ecosystem/go-grpc-middleware/blob/v1/logging/kit/ctxkit/context.go#L22-L28) Signed-off-by: Olivier Cano <[email protected]>
8e67a27
to
f34053b
Compare
I updated the descriptions of both:
|
Thanks for the explanation, but I'm a bit confused. This seems like an anti pattern to me. Contexts are generally immutable. Could you elaborate on the use case? |
The main use case is to add business-level attributes into the existing context so they appear in the final logs. func (s *server) GetFoo(ctx context.Context, _ *emptypb.Empty) (*bar.GetFooResponse, error) {
// Retrieve some metadata from the database
fooMetadata := model.GetFoo(ctx)
// AddFields makes these metadata visible from the "finished call" log
logging.AddField(ctx, "metadata", fooMetadata)
return &bar.GetFooResponse{...}, nil
} Another approach would be to generate another line of log at the business level, but the idea here is also to limit the amount of line of logs to 1 per unary method. I agree it does sound anti-pattern to use context this way, but I couldn't find a better workaround yet - I think this is why AddFields was added and maintained in the first place in the v1. |
Co-authored-by: Johan Brandhorst-Satzkorn <[email protected]>
Thanks for your contributino! |
Support the similar helpers from the v1 introduced in #91:
Use case: let an interceptor or the grpc method implemention add more fields to logging interceptor (e.g. "finished call").
Changes
fieldsCtxValue
structAddFields
TestAddFields
Verification
Old tests and new tests pass.