forked from golang/glog
-
Notifications
You must be signed in to change notification settings - Fork 218
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
klog always logs verbosity 0 with component-base/logs #294
Labels
kind/bug
Categorizes issue or PR as related to a bug.
Comments
/assign I intend to add a unit test to the new "test" package for this and then fix it. |
Thx! Happy to re-test with a branch/PR if it is helpful, but probably not needed as the issue seems to be relatively straightforward. |
pohly
added a commit
to pohly/klog
that referenced
this issue
Feb 14, 2022
To reproduce the loss of verbosity in klogr (kubernetes#294) we need a backend which actually emits the verbosity. zapr does that and also happens to be the logging implementation used in Kubernetes for JSON, so it makes sense to test with that. The expected output mapping may be useful also for testing in Kubernetes, therefore it gets exported by k8s.io/klog/v2/test. Because k8s.io/klog/v2 must not depend on zapr, the actual output test gets moved to the examples. The downside is that "go test ./..." no longer runs it. One has to remember to enter the "examples" directory. The GitHub action gets updated to do that.
Merged
pohly
added a commit
to pohly/klog
that referenced
this issue
Feb 14, 2022
To reproduce the loss of verbosity in klogr (kubernetes#294) we need a backend which actually emits the verbosity. zapr does that and also happens to be the logging implementation used in Kubernetes for JSON, so it makes sense to test with that. The expected output mapping may be useful also for testing in Kubernetes, therefore it gets exported by k8s.io/klog/v2/test. Because k8s.io/klog/v2 must not depend on zapr, the actual output test gets moved to the examples. The downside is that "go test ./..." no longer runs it. One has to remember to enter the "examples" directory. The GitHub action gets updated to do that.
pohly
added a commit
to pohly/klog
that referenced
this issue
Feb 14, 2022
To reproduce the loss of verbosity in klogr (kubernetes#294) we need a backend which actually emits the verbosity. zapr does that and also happens to be the logging implementation used in Kubernetes for JSON, so it makes sense to test with that. The expected output mapping may be useful also for testing in Kubernetes, therefore it gets exported by k8s.io/klog/v2/test. Because k8s.io/klog/v2 must not depend on zapr, the actual output test gets moved to the examples. The downside is that "go test ./..." no longer runs it. One has to remember to enter the "examples" directory. The GitHub action gets updated to do that.
pohly
added a commit
to pohly/klog
that referenced
this issue
Feb 14, 2022
To reproduce the loss of verbosity in klogr (kubernetes#294) we need a backend which actually emits the verbosity. zapr does that and also happens to be the logging implementation used in Kubernetes for JSON, so it makes sense to test with that. The expected output mapping may be useful also for testing in Kubernetes, therefore it gets exported by k8s.io/klog/v2/test. Because k8s.io/klog/v2 must not depend on zapr, the actual output test gets moved to the examples. The downside is that "go test ./..." no longer runs it. One has to remember to enter the "examples" directory. The GitHub action gets updated to do that.
pohly
added a commit
to pohly/klog
that referenced
this issue
Feb 15, 2022
To reproduce the loss of verbosity in klogr (kubernetes#294) we need a backend which actually emits the verbosity. zapr does that and also happens to be the logging implementation used in Kubernetes for JSON, so it makes sense to test with that. The expected output mapping may be useful also for testing in Kubernetes, therefore it gets exported by k8s.io/klog/v2/test. Because k8s.io/klog/v2 must not depend on zapr, the actual output test gets moved to the examples. The downside is that "go test ./..." no longer runs it. One has to remember to enter the "examples" directory. The GitHub action gets updated to do that.
pohly
added a commit
to pohly/klog
that referenced
this issue
Feb 15, 2022
To reproduce the loss of verbosity in klogr (kubernetes#294) we need a backend which actually emits the verbosity. zapr does that and also happens to be the logging implementation used in Kubernetes for JSON, so it makes sense to test with that. The expected output mapping may be useful also for testing in Kubernetes, therefore it gets exported by k8s.io/klog/v2/test. Because k8s.io/klog/v2 must not depend on zapr, the actual output test gets moved to the examples. The downside is that "go test ./..." no longer runs it. One has to remember to enter the "examples" directory. The GitHub action gets updated to do that.
Thanks for the quick fix! awesome! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
/kind bug
What steps did you take and what happened:
I'm currently trying to use
component-base/logs
in combination with controller-runtime in ClusterAPI (kubernetes-sigs/cluster-api#6072).When using
--logging-format=json
the log lines containv: 0
independent of the log level with which the line is actually logged.What did you expect to happen:
Should log the verbosity with which the log line is logged.
Anything else you would like to add:
When component-base/logs the "log hierarchy" is roughly go-logr.Logger => klog => JSON logger (component-base/logs) => zap:
I think the log level get's lost here: https://github.com/kubernetes/klog/blob/main/klogr/klogr.go#L169-L173
To reproduce:
I've created a minimal controller here: https://github.com/sbueringer/cr-klog-issue (with k8s.io/component-base v0.23.3 and k8s.io/klog/v2 v2.40.1)
The issue can be reproduced by running the controller against an arbitrary cluster (with Pods) via:
xref: Slack thread: https://kubernetes.slack.com/archives/CG3518SFJ/p1644596428193789
The text was updated successfully, but these errors were encountered: