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
[kube-proxy] add log verbosity to endpoint topology hint loop. #123322
[kube-proxy] add log verbosity to endpoint topology hint loop. #123322
Conversation
Hi @bjhaid. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Thanks! /lgtm |
LGTM label has been added. Git tree hash: 9acea8b3a387700d16f806d8ba2df268b862473b
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bjhaid, priestjim, thockin 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 |
Does this really solve anything? It seems like the real problem is that we need to throttle this notification |
@@ -166,7 +166,7 @@ func canUseTopology(endpoints []Endpoint, svcInfo ServicePort, nodeLabels map[st | |||
continue | |||
} | |||
if endpoint.ZoneHints().Len() == 0 { | |||
klog.InfoS("Skipping topology aware endpoint filtering since one or more endpoints is missing a zone hint", "endpoint", endpoint) | |||
klog.V(2).InfoS("Skipping topology aware endpoint filtering since one or more endpoints is missing a zone hint", "endpoint", endpoint) |
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.
should we switch all log statements to V(2) ?
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.
ping @robscott
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 think yes, outside of all the startup logs most or all log sites should be V(N)
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.
do you want to change it?
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 mean, the two other logs statements in this function, they will have the same issue
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.
do you want to change it?
I didn't want to start combing through all kube-proxy logs sites to update in this PR
I mean, the two other logs statements in this function, they will have the same issue
I can update those as well, just started with the most annoying, the other 2 combined for ~6M lines/day which is way less than the one I started with. I'll push changes to update the other log statements as well.
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.
updated the other 2 locations in this file. If I can find time I'll look into sending a PR for all of kube-proxy, but I can't guarantee that will happen today.
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.
Yeah this seems like a good improvement, thanks @bjhaid!
the logs is maybe useful for debugging, but it is noise for me as a cluster operator. I believe one should be able to turn off all none fatal/bootup logs. So yes while throttling might help, the log and a bunch of logs from kube-proxy today is noise, I almost never look at them unless I am troubleshooting stuff and I'll like to be able to turn most of them of and on as I wish. |
We enabled topology hint on one of our services and this log line was emitted ~92 million times in one day from one cluster tripping our log quota for that cluster, as it is the log line cannot be disabled via the `-v` flag because it does not specify verbosity. I think more log locations need to set verbosity at which they are logged, but this one is currently hurting the most.
d4da510
to
71479b5
Compare
/ok-to-test @danwinship I think that is fair ask to be able to disable them , are you ok with this? |
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.
Thanks @bjhaid! This is a great fix - I'd also be open to @danwinship's suggestion of some kind of throttling here, but setting a log level like this does seems like a great improvement that we could build on in the future.
/lgtm
@@ -166,7 +166,7 @@ func canUseTopology(endpoints []Endpoint, svcInfo ServicePort, nodeLabels map[st | |||
continue | |||
} | |||
if endpoint.ZoneHints().Len() == 0 { | |||
klog.InfoS("Skipping topology aware endpoint filtering since one or more endpoints is missing a zone hint", "endpoint", endpoint) | |||
klog.V(2).InfoS("Skipping topology aware endpoint filtering since one or more endpoints is missing a zone hint", "endpoint", endpoint) |
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.
Yeah this seems like a good improvement, thanks @bjhaid!
LGTM label has been added. Git tree hash: e854e0f912af8cff0490b1b035871d0ba41664dc
|
/triage accepted |
…f-#123322-upstream-release-1.28 Automated cherry pick of #123322: add log verbosity to endpoint topology hint
…f-#123322-upstream-release-1.29 Automated cherry pick of #123322: add log verbosity to endpoint topology hint
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
We enabled topology hint on one of our services and this log line was emitted ~92 million times in one day from one cluster tripping our log quota for that cluster, as it is the log line cannot be disabled via the
-v
flag because it does not specify verbosity.I think more log locations need to set verbosity at which they are logged, but this one is currently hurting the most.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: