-
Notifications
You must be signed in to change notification settings - Fork 644
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
Eliminate logspam using filelog monitor #1032
base: master
Are you sure you want to change the base?
Conversation
When using a filelog monitor, the top-level `pluginConfig.message` filter provides a limited stream of log events to be checked against the `rules[].pattern`. I thus expect it to be normal for most log events to fail to match the top-level `pluginConfig.message` filter. Such a condition should not trigger a warning-level log message. And in fact such log messages should be suppressed by default, unless `-v=5` or higher is used for troubleshooting/debug purposes.
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: skaven81 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The committers listed above are authorized under a signed CLA. |
Welcome @skaven81! |
Hi @skaven81. 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-sigs/prow repository. |
/ok-to-test |
When using a filelog monitor, the top-level
pluginConfig.message
filter provides a limited stream of log events to be checked against therules[].pattern
. I thus expect it to be normal for most log events to fail to match the top-levelpluginConfig.message
filter. Such a condition should not trigger a warning-level log message. And in fact such log messages should be suppressed by default, unless-v=5
or higher is used for troubleshooting/debug purposes.