-
Notifications
You must be signed in to change notification settings - Fork 39
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
Reduce the log noise caused by core report summary #1426
Conversation
Signed-off-by: Ahmed Hussein (amahussein) <[email protected]> Contributes to NVIDIA#1416 This change set the log level of ToolTextFileWriter to debug and summarize the logging into a single message to show the final directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @amahussein. LGTME. One minor comment.
@@ -70,7 +70,7 @@ class ToolTextFileWriter( | |||
// No need to close the outputStream. | |||
// Java should handle nested streams automatically. | |||
utf8Writer.foreach { writer => | |||
logInfo(s"$finalLocationText output location: $textOutputLoc") | |||
logDebug(s"$finalLocationText output location: $textOutputLoc") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be unnecessary but should we consider adding a single INFO level log per app indicating successful output generation, instead of logging for each individual file?
Again, it is unnecessary because these metrics are primarily for our internal use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know if I get your comment.
Do you mean some sort of a summary of files that were generated but put them in a single message?
- If that's the case, then I think we will hit the same issue that we have on the python side and Qualx. For example, when we generated tree of the output; it became too long. So, I believe if we put a single LogInfo message that contains list of all metrics generated, then the list will keep growing and I don't see that very useful information to put in the logging message.
- In that change I changed the debug-level so that it does not get generated by default in production.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of a single log line like:
INFO: Successfully generated output files for app <app-id> at <metrics location dir>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! For now this PR does exactly that.
We can later improve the implementation if we want the debug-level to be a single message as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @amahussein! QQ: this is only for switching the printing of output file names to debug
, is that right?
Signed-off-by: Ahmed Hussein (amahussein) [email protected]
Contributes to #1416
This change set the log level of ToolTextFileWriter to debug and summarize the logging into a single message to show the final directory
example output after the changes: