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

logging: include information about contextual logging #6560

Merged
merged 1 commit into from
Apr 11, 2022

Conversation

pohly
Copy link
Contributor

@pohly pohly commented Mar 23, 2022

In Kubernetes 1.24, the necessary infrastructure got added. Now developers can
take advantage of it.

@pohly
Copy link
Contributor Author

pohly commented Mar 23, 2022

/wg structured-logging
/sig instrumentation

logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging#transition). It
also lists several
[pitfalls](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging#pitfalls-during-usage)
that developers and reviewers need to be aware of.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I decided against copying the text because then we would have to maintain it in two places. Can we assume that readers of this document here will follow the links?


Calling `ErrorS` with `nil` as error is semi-acceptable if there is error condition that deserves a stack trace at this
Copy link
Contributor Author

@pohly pohly Mar 23, 2022

Choose a reason for hiding this comment

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

Printing a stack trace is not the main difference between InfoS and ErrorS, and neither text nor JSON output include a stack trace for ErrorS.

I'm wondering whether that should be documented, because if a stack trace is desired, then the suggested replacement is loosing that information. In kubernetes/klog#316 I am proposing some new helper functions that could be used to address this gap. Should we try to get that into Kubernetes 1.24 together with FlushAndExit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Too late for 1.24...

Copy link
Contributor

Choose a reason for hiding this comment

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

When writing this document we wanted a clear way for users to decide whether they should use Info or Error. An error that doesn't happen during routine operation and deserves a stacktrace was a distinction proposed by @thockin. In the end didn't implement writing stacktrace.

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Mar 23, 2022
@k8s-ci-robot k8s-ci-robot added the area/developer-guide Issues or PRs related to the developer guide label Mar 23, 2022
@k8s-ci-robot k8s-ci-robot added sig/instrumentation Categorizes an issue or PR as relevant to SIG Instrumentation. wg/structured-logging Categorizes an issue or PR as relevant to WG Structured Logging. labels Mar 23, 2022
@pohly
Copy link
Contributor Author

pohly commented Mar 23, 2022

/hold

Code PRs needs to be merged first.

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 23, 2022
@logicalhan
Copy link
Member

/assign

@pohly
Copy link
Contributor Author

pohly commented Apr 4, 2022

/hold cancel
/assign @serathius

Code PRs are all merged, contextual logging is alpha in 1.24. Let's finish the documentation... 😁

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 4, 2022
## Migration

1. Change log functions to structured equivalent
1. Find code locations that need to be changed:
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 that this tool would be better to verify the results than find code locations.

Copy link
Contributor

Choose a reason for hiding this comment

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

Could make it part of Verify log output?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that this tool would be better to verify the results than find code locations.

Then how do you suggest that developers should find code locations instead? Using "git grep" easily leads to false positives. The logcheck tool is more precise.

Could make it part of Verify log output?

That section is about something else (the output that gets generated, not how it gets generated). I can add a "Preventing regressions" section and there describe how we use hack/logcheck.conf to ensure that undesirable calls do not get added back into already converted packages.

@thockin
Copy link
Member

thockin commented Apr 4, 2022 via email

@pohly
Copy link
Contributor Author

pohly commented Apr 4, 2022

I think there will always be times when I have an "error situation"
(something bad happened, but I am not reporting it further up-stack - maybe
I will retry or something) but I do not have a literal error type
variable. log.ErrorS() is still appropriate, IMO

And that's why both klog.ErrorS and logger.Error allow the err parameter to be nil, so it's not just "semi-acceptable" (old wording, now removed) but encouraged to use the error functions for error situations.

updated. If there are any `context.TODO` calls in the modified functions,
replace with the new `ctx` parameter.

In performance critical code it may be faster to add a `logger klog.Logger`
Copy link
Member

Choose a reason for hiding this comment

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

Do you have any hard numbers on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did some microbenchmarking for the KEP: kubernetes/enhancements#3078 (comment)

Those tests are pending for Kubernetes: https://github.com/kubernetes/kubernetes/pull/109194/commits

In Kubernetes 1.24, the necessary infrastructure got added. Now developers can
take advantage of it.
Copy link

@chrisnegus chrisnegus left a comment

Choose a reason for hiding this comment

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

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 11, 2022
@chrisnegus
Copy link

chrisnegus commented Apr 11, 2022

/assign @nate-double-u
docs 1.24 lead

@nate-double-u
Copy link
Contributor

Not sure if I'm able to approve in this repo, but this looks good to me.
/approve

@pohly
Copy link
Contributor Author

pohly commented Apr 11, 2022

/assign @serathius

For final review and approval.

@serathius
Copy link
Contributor

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nate-double-u, pohly, serathius

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 11, 2022
@k8s-ci-robot k8s-ci-robot merged commit 287702e into kubernetes:master Apr 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/developer-guide Issues or PRs related to the developer guide cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/instrumentation Categorizes an issue or PR as relevant to SIG Instrumentation. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. wg/structured-logging Categorizes an issue or PR as relevant to WG Structured Logging.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants