-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Logging: Startup messages log level #1854
Comments
Most of these messages used to be "notice" level before spdlog removed that level and we switched them all to warn. |
Hi... Was interested in trying an easy task as an intro to envoy. This one looks like it might be appropriate. What's the thinking on strategy here? Make the startup messages be 'info' and have info messages visible during startup by default and and hidden afterward? Other ideas? |
@jmarantz my thinking on this is:
|
Got it.I will scope this out. It seems simple enough but likely touches a bunch of files. If the messages can be reasonably judged on text alone, context-free, it may be straightforward enough, and would take me on a nickel your through the code. |
There appear to 37 info messages and 31 warnings. Default loglevel is established in ./exe/main.cc:45 I believe. Looks like a good intro task. |
11 references to ListenerImpl::infoLog as well. There are a handful of info messages that appear to be startup-time only. Leaving those as is, assuming a little startup noise is OK, but that we are trying to avoid a lot of per-connection logging. I also found 3 instances of this:
I'm guessing this was done as a deliberate attempt to reduce 'network error' noise going into the logs regularly. Is that right? In that case I think the 'network' error path should be changed to debug. |
@jmarantz yup all of ^ LGTM. |
Great. I have a change which passes tests, I think, but I would like to see a server under load and measure impact on log size. What's the best way to do that? |
@jmarantz not sure, you could try running integration tests at info level potentially and see what prints. You could also try out https://github.com/envoyproxy/envoy-perf. |
(In general there should be almost no logging at info level once the server starts up and is forwarding traffic). |
Sorry for the delay -- had some other things going on, and needed to do a bit of learning to understand how to run integration tests. Those exposed some other potentially noisy info logs, some of which were obvious and I fixed. But in testlogs/test/integration/hotrestart_test/test.log I have a case I'm not sure how it's best to handle. I have lots of log entries like this: [2017-11-09 16:20:48.257][53716][info][upstream] source/common/upstream/cluster_manager_impl.cc:62] cm init: adding: cluster=cluster_2 primary=0 secondary=0 and [2017-11-09 16:20:48.284][53716][info][config] source/server/configuration_impl.cc:47] listener #4: A burst of a few few dozen of those on startup seem OK. But in this test there 8 such bursts of several dozen. I think this is the nature of the test (hot restart) but I thought I'd just note this concern and see whether these config-type messages should be moved to debug. |
@jmarantz yeah I would just move all those to debug. |
Got rid of those, but these still remain. From running all integration tests, I then ran this to look at log noise:
Basically this pipe shows me the sources of messages that come out most frequently in the integration tests. Full results below. I think these seem reasonable but happy to trim further. The remaining high frequency messages all seem to be per server startup or config, not per request:
|
@jmarantz good stuff. I would say at this point just post a PR. We can review there / people can run locally if they want to check it out? |
This reverts commit f85f49c.
Startup messages are currently logged at a
warning
level, but should probably be at adebug
orinfo
level.Simply changing their level will likely hide them by default and that is probably undesirable (these messages should probably always be printed).
The text was updated successfully, but these errors were encountered: