-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[public-api] Use context logger #16686
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
Conversation
/werft run 👍 started the job as gitpod-build-mp-papi-log-context.6 |
/werft run 👍 started the job as gitpod-build-mp-papi-log-context.7 |
started the job as gitpod-build-mp-papi-log-context.8 because the annotations in the pull request description changed |
a0c701f
to
fb9b0a8
Compare
@@ -38,6 +40,9 @@ func (s *UserService) GetAuthenticatedUser(ctx context.Context, req *connect.Req | |||
if err != nil { | |||
return nil, proxy.ConvertError(err) | |||
} | |||
log.AddFields(ctx, logrus.Fields{ | |||
"user.id": user.ID, |
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.
w.r.t to log-shapes: so far we follow this format, which is the same across logs and traces, in TS and Go (in most places 🙃 ).
Not particularly attached to that specific format, but would be great to stay consistent within the app. Plus the existing format is imprinted into quite some 🧠s already 😉
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.
Using the .
format means it auto-unpicks them as nested properties of these structures, so they get treated more as JSON, rather than as plain strings
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.
Basically, in a log viewer you see it as "user": { "id": val } which means you group the properties of a user together
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.
I get that there are benefits to either side. I just want us to stay consistent, so I don't have to recall multiple formats.
Do you see any possibility we can achieve both? Like, fill multiple fields? 🤷
Also, in theory happy to adjust it everywhere. But I guess that's not worth the effort.
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.
With this change, the logging in public-api
is "standardised" to the .
format. I don't really see much value in duplicating the fields currently. We can update server to use a similar format as well
9b01e3d
to
c245a88
Compare
func validateTeamID(id string) (uuid.UUID, error) { | ||
func validateTeamID(ctx context.Context, id string) (uuid.UUID, error) { | ||
log.AddFields(ctx, logrus.Fields{ | ||
"team.id": id, |
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.
func validateWorkspaceID(id string) (string, error) { | ||
func validateWorkspaceID(ctx context.Context, id string) (string, error) { | ||
log.AddFields(ctx, logrus.Fields{ | ||
"workspace.id": id, |
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.
func validateProjectID(id string) (uuid.UUID, error) { | ||
func validateProjectID(ctx context.Context, id string) (uuid.UUID, error) { | ||
log.AddFields(ctx, logrus.Fields{ | ||
"project.id": id, |
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.
func validatePersonalAccessTokenID(id string) (uuid.UUID, error) { | ||
func validatePersonalAccessTokenID(ctx context.Context, id string) (uuid.UUID, error) { | ||
log.AddFields(ctx, logrus.Fields{ | ||
"pat.id": id, |
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.
logger.WithField("headers", req.Header()).Debugf("Handling request for %s", req.Spec().Procedure) | ||
} | ||
log.AddFields(ctx, logrus.Fields{ | ||
"request.protocol": "connect", |
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.
Similarly, it would be great to have a "standardized" way to log these things across the app.
But as we don't have anything here, yet, fine with this.
c245a88
to
b92b44e
Compare
Spoke sync. In this PR, I've changed it to use the current format. Subsequent PR will propose changing the format of the log fields such that we benefit from the log viewer representation of fields. This allows us to land the context logging itself here. |
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.
👍
started the job as gitpod-build-mp-papi-log-context.17 because the annotations in the pull request description changed |
/unhold |
Description
Adds structured log fields to logs to provide more context on the request/resource/user.
Related Issue(s)
Fixes #
How to test
Release Notes
Documentation
Build Options:
Experimental feature to run the build with GitHub Actions (and not in Werft).
leeway-target=components:all
Run Leeway with
--dont-test
Publish Options
Installer Options
Add desired feature flags to the end of the line above, space separated
Preview Environment Options:
If enabled this will build
install/preview
If enabled this will create the environment on GCE infra
Valid options are
all
,workspace
,webapp
,ide
,jetbrains
,vscode
,ssh
/hold