Change:
const klogWrapperDepth = 4 func (klogWrapper) Info(args ...interface{}) { <del> klog.InfoDepth(klogWrapperDepth, args...) </del> <ins> if klog.V(5).Enabled() { klog.InfoDepth(klogWrapperDepth, args...) } </ins> } func (klogWrapper) Infoln(args ...interface{}) { <del> klog.InfoDepth(klogWrapperDepth, fmt.Sprintln(args...)) </del> <ins> if klog.V(5).Enabled() { klog.InfoDepth(klogWrapperDepth, fmt.Sprintln(args...)) } </ins> } func (klogWrapper) Infof(format string, args ...interface{}) { <del> klog.InfoDepth(klogWrapperDepth, fmt.Sprintf(format, args...)) </del> <ins> if klog.V(5).Enabled() { klog.InfoDepth(klogWrapperDepth, fmt.Sprintf(format, args...)) } </ins> } func (klogWrapper) Warning(args ...interface{}) {

Discussion:
What happened: we are running apiserver with loglevel 1. However, we are seeing still quite much logs coming from apiserver. ~1800 rows/hour in empty cluster (3 masters, so one apiserver making ~600 rows/hour) Example: What you expected to happen: I expect that if we run apiserver with loglevel 1 we should only see log rows that we are interested of and are important. As I see it, these log rows are not really important and should not be visible. How to reproduce it (as minimally and precisely as possible): put apiserver to loglevel 1 and check the log files after that. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20.2 Cloud provider or hardware configuration: openstack OS (e.g: ): debian buster Kernel (e.g. ): Install tools: kops Network plugin and version (if this is a network-related bug): Others: /kind bug
/sig api-machinery
/assign /triage accepted
and
Any update on this? This makes debugging more painful. There's a lot of noise. cc
the problem is that these log rows are not coming from this repository. Instead these are coming from for instance is coming from ... which means that it does not matter what loglevel that lib has, it will be always printed still. they have changed logging stuff in latest grpc-go and there are some new env variables but no idea can those still be ignored. perhaps not
I don't think GRPC logs klog style lines on its own?, wherever we have the logging adapter we could handle this on our end.
Our shim should probably map GCPC info =V(N) for some N 1.
I found similar issue with PR I think it could solve this issue also.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
still an issue after update to etcd 3.5.0 and latest grpc in
is there a recommended way to quiet the etcd client logs with the new logging setup in 3.5.0?

potential solution in
Do you understand the source of this logs ? From the high-level glance they might be a syndrome / optimization opportunity: -3.5. configures clientv3 to use 'roundrobin' balancer by default: is it aware decision of api-server to override it to 'pick_first' ? Or the logs are from pre-3.4 and the 3.5 spams with different messages ? assume each of this log-lines is somewhat related to creation of clientv3 object instances (or at least connection management within each client, that do not share the connections pool). Taking in consideration that mTLS shandhake on connection is computationally costly, there might be an area for perf improvement.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Integration with third party logging should be in scope of SIG Instrumentation and WG structured logging. /sig instrumentation /wg structured-logging
the API server sets up the etcd client here, and doesn't override options like that: The specific messages in the description were from an older etcd client, the messages were different in 3.5.0, but still spammy the issue with excessive logging is resolved. If we want a different issue to track log integration, let's open one specifically for that purpose. /close
Closing this issue. <detailsIn response to : is it aware decision of api-server to override it to 'pick_first' ? Or the logs are from pre-3.4 and the 3.5 spams with different messages ? Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
It seems I should upgrade kubernetes version to 1.22 to solve this problem...