Bug 1414813
Summary: | OCP 3.5: log spam: at loglevel=2 all REST calls are being logged in the master logs | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Mike Fiedler <mifiedle> |
Component: | Node | Assignee: | Avesh Agarwal <avagarwa> |
Status: | CLOSED NOTABUG | QA Contact: | Mike Fiedler <mifiedle> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 3.5.0 | CC: | aos-bugs, avagarwa, clichybi, decarr, eparis, jokerman, jrosenta, mmccomas, sjenning, sreber, tparsons |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Previously REST API calls were being logged at log level 2 which is the default level and due to this, lot of logs were being generated and it was hard to see during debugging what went wrong. With this fix, REST API calls logging is moved to log level 3 to avoid them being logged by default.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2017-08-24 15:10:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mike Fiedler
2017-01-19 14:19:34 UTC
The --loglevel option is really a bad name as people associate it with syslog-type loglevels. Really, it is a "debug verbosity level", more like -vv in other commands. --loglevel should only be set when debugging where verbose logs are desired. When --loglevel is not set, you still get ERROR, WARNING, and INFO level messages in the log. Is there a particular reason you are running with --loglevel=2? That is the default loglevel QE has run with in the past. Generally we want enough logging so that if problems occur, the logs are useful to development in case the problem is not easily recreateable. Ok, let me see if someone changed it upstream for 1.5 and, if so, determine the reason for doing so. Avesh - can you track down if there was a change in behavior and why? yeah sure, will look into it soon. I think I have found a solution and I am doing some testing and will report back soon. I sent following PR to kube upstream to address this issue: https://github.com/kubernetes/kubernetes/pull/40933 Verified these messages do not appear in OCP 3.4 when the master is at loglevel 3.4 (In reply to Eric Paris from comment #10) > same as https://github.com/openshift/origin/issues/13724 Help get this https://github.com/kubernetes/kubernetes/pull/40933 merged. Verified on 3.6.99 This was regressed in the 1.7 rebase. I opened https://bugzilla.redhat.com/show_bug.cgi?id=1484095 to track it. Marking as closed, since this was fixed in 3.6 and the BZ was targetting a fix in 3.6 I think it would be --v=2 --vmodule="panics=4" What was the error message? It is --loglevel in openshift (In reply to Seth Jennings from comment #23) > It is --loglevel in openshift loglevel is only for --v, the other thing here is how to configure vmodule in openshift. Yes, I was replying specifically to the --v error. I've looked in the code and it doesn't look like openshift allows vmodule to be set by users, which is unfortunate. As per Seth last comment I understand there is no current workaround for this bug in OCP 3.5 apart from setting loglevel=1 then? (In reply to Joel Rosental R. from comment #26) > As per Seth last comment I understand there is no current workaround for > this bug in OCP 3.5 apart from setting loglevel=1 then? Hi Joel, David (@deads) told me that there is another flag --logspec that maps to vmodule, that can be used to configure per module/file logging. So it seems, you could try: --logpsec='log=3'. Let me know if this works for you or not. So I think I have investigated it and I am seeing same behaviour that using logspec does not lower log level to 1. The reason is that it seems glog's behavior that I have observed is that logspec can help to go above specified loglevel for a particualar file, but it is never going below specified loglevel. For example, if loglevel is 2, logspec can help go to higher levels > 2 for a particular file, but it never goes below 2. Similarly if loglevel is at 3, logspec can help go > 3 but it never goes down to 2 or lower. I am not sure if glog did it intentionally or it's a bug in glog but it is what it is. Right now, as I see is to handle this issue is to patch openshift like we have done for 3.6/3.7. |