-
Notifications
You must be signed in to change notification settings - Fork 43
Change log level of detailed tracing messages to TRACE instead of DEBUG #1409
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
Conversation
Signed-off-by: Christian Vetter <christian.vetter@here.com>
Codecov Report
Merging #1409 (5e0ccc4) into master (7b0c381) will increase coverage by
0.02%.
The diff coverage isn/a.
❗ Current head 5e0ccc4 differs from pull request most recent head 59730bc. Consider uploading reports for the commit 59730bc to get more accurate results
@@ Coverage Diff @@ ## master #1409 +/- ## ========================================== + Coverage 80.59% 80.60% +0.02% ========================================== Files 337 337 Lines 12780 12781 +1 Branches 1385 1386 +1 ========================================== + Hits 10299 10302 +3 + Misses 1914 1913 -1 + Partials 567 566 -1
see 2 files with indirect coverage changes
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more
Any feedback on this?
This looks like a reasonable change to me.
I assume it's intentional that only "send" and "cancel" are dropped to TRACE, but not "message completed"?
@uhertlein I guess that's because those message were the only ones spamming in my apps :)
Which messages would you suggest to also downgrade?
I didn't want to suggest to change more message to TRACE.
Keeping "Message completed" at DEBUG is good IMO, because it contains enough information to make "Send request" semi-redundant.
Have you considered changing the log level on your side (you can change it for CURL only
@mykhailo-kuchma sure, but then you hide other logging information as a side-effect. So the question is what you would expect conceptually on each level.
TRACE: detailed information about what is going one, expensive to log (lots of log output)
DEBUG: Extra information for weird things going on
INFO: Information you need if everything works normally
WARNING: Something is potentially broken
ERROR: Something is definitely broken
It makes sense to think this through and then put each piece of information were it belongs.
For me this seemed to fit TRACE very well, since you have a huge amount of log output (e.g. if using a simple renderer that downloads 100+ partitions when scrolling across the map)
One of the main things the SDK does is issue network requests. These are issued all the time, and outputting log messages for them is more akin to tracing the debug logging. The same is true for cancelling network requests: Rendering libraries will typically cancel requests if you pan the map.
Without this change debug logs are extremely spammy and hard to analyze.
What do you think?