Logging: Add klog override matcher to remap certain errors to "info" level #35942
Conversation
|
/test |
95006b0 to
c743ebd
Compare
c743ebd to
0d43ee9
Compare
|
Instead of remapping the errors to info level, have you considered just ignoring the error in the connectivity tests, like we do for other error logs? |
|
Upon closer inspection, it seems like we already ignore it: and Any idea why this is not enough to ignore it? |
@tklauser This fundamentally doesn't feel like a error to me, hence the thinking was that we still want to display it to users, but it would be misleading to emit it as a error since it doesn't inherently imply any degradation. This is quite a bit of change for such a small issue, but the intention was to setup the code to future such remappings. Maybe we should just propose changing the log level upstream in k8s client-go however, and ignore it for now. |
The semicolon is breaking the matching, the log currently appears as: |
That makes sense, thanks for the explanation.
Let's hope we won't need it too often 😅
Yeah, that would IMO be the optimal solution. |
0d43ee9 to
b350373
Compare
|
/test |
b350373 to
38c9dee
Compare
|
/test |
38c9dee to
bb05b01
Compare
|
/test |
Add functionality to intercept and remap log levels of klogs being emitted with logrus loggers. This reimplements some of the klog functionality that listens/writes on a io.Pipe when klog messages come in but additionally matches lines against remappings. If such a override matches, the log will be redirected to the specified alternate log level logrus logger. This will allow us to change the level of emitted klogs logs such that users still see the log event but in the case where it does not amount to an error as far as Cilium functionality goes we can just reduce it down to info, etc. Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com>
Using functionality added in previous commits, this adds a matcher override case that will emit the error log: `Failed to update lock optimitically ... falling back to slow path` (note: as well as the correct spelling, as that has been fixed upstream). Looking at the client-go case where this log happens [1], the intended behavior is that the leader lock is assumed to be valid with the fallback behavior being to get the election record. This seems like a normal set of operations, so we shouldn't consider this case a error outright. Thus this being logged as an error is likely to be confusing to users. However, it would be useful to still have this information logged so we will use the klog level remapping to override this specific error. Subsequent errors while attempting leader election will be emitted by client-go as normal. [1] https://github.com/kubernetes/client-go/blob/v0.31.2/tools/leaderelection/leaderelection.go#L417-L430 Fixes: cilium#31374 Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com>
bb05b01 to
2642554
Compare
|
/test |
Fixes: #31374