logger: macros evaluate logging level before invoking logger #2751
logger: macros evaluate logging level before invoking logger #2751mattklein123 merged 8 commits intoenvoyproxy:masterfrom
Conversation
…age severity. Code passed to logger as params will NOT be evaluated if message's severity is lower than logger's severity. Signed-off-by: Christoph Pakulski <paker8848@gmail.com>
Added test to verify that the macro can be used inside if .. else ... Signed-off-by: Christoph Pakulski <paker8848@gmail.com>
…nvoy namespace. Signed-off-by: christoph <paker8848@gmail.com>
…:Logger. There are some benchmark tests which invoke logger from default namespace. Signed-off-by: Christoph Pakulski <paker8848@gmail.com>
If NVLOG is defined, trace and debug logging macros are evaluated to empty lines. Signed-off-by: Christoph Pakulski <paker8848@gmail.com>
|
@mrice32 sorry for the hot spotted load balancing here, but can you also look at this one as this is your code? Thanks. |
| } | ||
| } | ||
|
|
||
| #ifdef NVLOG |
There was a problem hiding this comment.
Does the CI ever run in a mode with NVLOG defined? Put another way, will this test ever be executed by the CI or will it always be compiled out?
There was a problem hiding this comment.
CI probably never runs with NVLOG defined. I invoked the test manually by running
bazel test --copt=-DNVLOG //test/common/common:log_macros_test
There was a problem hiding this comment.
Should we set one of the circleCI jobs to define NVLOG? Maybe the "release" job?
There was a problem hiding this comment.
That is probably good idea. I was surprised when my first PR #2676 was reverted even though it passed CI checks. If "release" CI job tests release image, it should probably use "release" compile flags.
There was a problem hiding this comment.
@ggreenway I don't think we should do it on the release job because that job is used for building the docker images.
Not to throw a wrench in this, but I'm wondering with all the macros we have now and this change, if we should just kill NVLOG entirely. There is some perf benefit but now that the logs don't evaluate it's probably small.
I think all that would be needed is to add some type of macro/guard for the few places where we use NVLOG to block an expensive iteration. Thoughts?
There was a problem hiding this comment.
Performance overhead is one function call and comparison between integers. Not much.
I just hope that trace and debug logs do not display sensitive information. With NVLOG they are just removed. If NVLOG is killed, all is required to display those logs is to lower severity level.
There was a problem hiding this comment.
I think at this point I would vote to just kill NVLOG and replace with some additional macros for the places in which we use it for larger guards, but no objection to merging this PR.
There was a problem hiding this comment.
@cpakulski are you interested in just getting rid of NVLOG as part of this PR?
mrice32
left a comment
There was a problem hiding this comment.
Two small nits - after that LGTM. Thanks for adding this! Sorry this has been so troublesome to get in, but I think it revealed some holes in our CI, which is awesome.
|
|
||
| #ifdef NVLOG | ||
| TEST(Logger, doNotExpandTraceAndDebug) { | ||
| // The following two macros should not be expanded to no-op if NVLOG compile flag is defined. |
There was a problem hiding this comment.
nit: I realize that this is just a test to ensure they compile, but do we also want to add the incrementing counter behavior used above just to ensure the statements act as stated?
There was a problem hiding this comment.
Done. Thanks for review and suggestions.
| TEST(Logger, logAsStatement) { | ||
| // Just log as part of if ... statement | ||
|
|
||
| if (true) |
There was a problem hiding this comment.
nit: same here as below, can we just add simple counter behavior above to ensure that this test not only compiles, but that it acts as expected?
alyssawilk
left a comment
There was a problem hiding this comment.
Looks great! Thanks for plugging away at this one :-)
| TEST(Logger, doNotEvaluateParams) { | ||
| uint32_t i = 1; | ||
|
|
||
| // set logger's logging level high and log a message with lower severity |
There was a problem hiding this comment.
Super nitty, mind set ->Set here and above and do -> Do on 69?
There was a problem hiding this comment.
Thanks for catching it. It has been corrected.
Signed-off-by: Christoph Pakulski <paker8848@gmail.com>
| // log message with higher severity and make sure that params were evaluated. | ||
| GET_MISC_LOGGER().set_level(spdlog::level::info); | ||
| ENVOY_LOG_MISC(warn, "test message '{}'", i++); | ||
| ASSERT_THAT(i, testing::Eq(2)); |
There was a problem hiding this comment.
nit: prefer EXPECT* for non-fatal failures, since ASSERT* will essentially abort the test case. Here and elsewhere.
There was a problem hiding this comment.
Good suggestion. Done.
Testing will continue even when one test fails. Signed-off-by: Christoph Pakulski <paker8848@gmail.com>
Signed-off-by: Christoph Pakulski <paker8848@gmail.com>
|
If there are any other comments related to this PR, they will have to wait - I will be away for few days. |
|
@mattklein123 sure - I can remove NVLOG. I am away though for few days.
On Mar 9, 2018 3:02 PM, "Matt Klein" <notifications@github.com> wrote:
*@mattklein123* commented on this pull request.
------------------------------
In test/common/common/log_macros_test.cc
<#2751 (comment)>:
+ // Just log as part of if ... statement
+
+ if (true)
+ ENVOY_LOG_MISC(critical, "test message 1");
+ else
+ ENVOY_LOG_MISC(critical, "test message 2");
+
+ // do the same with curly brackets
+ if (true) {
+ ENVOY_LOG_MISC(critical, "test message 3");
+ } else {
+ ENVOY_LOG_MISC(critical, "test message 4");
+ }
+}
+
+#ifdef NVLOG
@cpakulski <https://github.com/cpakulski> are you interested in just
getting rid of NVLOG as part of this PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2751 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/Aiy1DlAGE75oMLso-SxQK4fL8OfJ_oSdks5tct-_gaJpZM4ShLzL>
.
|
|
@cpakulski no problem, take your time. Thank you! |
|
Per new release note policy please add a release note with any applicable feature docs to https://github.com/envoyproxy/data-plane-api/blob/master/docs/root/intro/version_history.rst. Thank you! |
|
@mattklein123 @ggreenway I would prefer to remove NVLOG flag as a separate PR. My main concern is that if for any reason (performance for example) those changes have to be removed, it will be easier to revert. If you agree, please merge this PR #2751 and open a new issue to track removal of NVLOG flag. |
|
@cpakulski sure, that's fine. I opened #2854 to track. |
…g levels. (envoyproxy#2984)" This reverts commit 4874315. As pointed out by @alyssawilk, this doesn't make sense given envoyproxy#2751. I think the profile that motivated this must have been created before the Google import included envoyproxy#2751. Signed-off-by: Harvey Tuch <htuch@google.com>
Description: logger's current severity level is checked before calling logger's API. This avoids evaluating parameters passed to the logger when message severity is lower than logger's setting. Before this change, params were evaluated even when the message was later on dropped by logger. This addresses issue #2330. First PR #2676 was reverted because code did not compile when NVLOG compile flag was enabled. This has been fixed and test for this case has been added.
Risk Level: Medium. This is simple fix, but the code is extensively used across the project.
Testing: unit tests: added 3 tests to test/common/common/log_macros_test.cc. Added test to makes sure that code compiles when NVLOG is defined.
Docs Changes: N/A
Release Notes: N/A