Stop flooding the terminal by default with all matches, switch to debug if desired#364
Conversation
ct2034
added
enhancement
This monitor was not modified in this PR. I'll rebase to see if that helps. |
Timple
force-pushed
the
silence-matching-loggers
branch
from
ed3377a to
c0a8297
Compare
|
Ping @ct2034 Any objections here? |
|
Or can this at least get in before Kilted? 🙂 |
| has_initialized_ = true; | ||
|
|
||
| RCLCPP_INFO( | ||
| RCLCPP_DEBUG( |
There was a problem hiding this comment.
Can we please keep those messages that are not triggered per match on info
|
Hey @MCFurry @Timple |
…e initial log of the function
|
Sorry it took a while! |
|
Based on what we discussed above, that I am happy to change the level in the In any case, I think this would also be a good use for RCLCPP_DEBUG_THROTTLE. What do you think? |
ct2034
added
the
needs more work
|
The issue is that there a loop around all parameters: for (const auto & param : parameters) {Every analyzer added prints information about all other analyzers as well. Since we have a lot of analyzers, adding only 1 causes a massive print flood. |
|
@ct2034 if you like things to be verbose, do you have any ideas how to get around printing always all parameters? |
| init_ok = false; | ||
| RCLCPP_ERROR(logger_, "No analyzers initialized in AnalyzerGroup '%s'", n->get_namespace()); | ||
| } else { | ||
| RCLCPP_INFO( |
There was a problem hiding this comment.
Could we not change these? They don't get executed per match, or do they?
There was a problem hiding this comment.
Not per match, but per init. And every time aadd_analyzer triggers a parameter event, it fully destroys and fully rebuilds the entire AnalyzerGroup. So this does lead to excessive logging.
There was a problem hiding this comment.
Okay, so I guess the flooding here only ocurrs in scenarios with dynamic configuration.
Could we do something where it is an info if the aggregator is new and else debug? Would this work. It would make the implementation slightly more complex, though
There was a problem hiding this comment.
In anticipation of this request I already dived into that.
-
Pragmatic approach:
- Track existing analyzer names before re-init, then suppress logs for already-known ones.
-
Support incremental adds
- Quite significant rewrite (including some bookkeeping).
-
Making log level a user preference
- Quite easy with a parameter I guess.
I am currently trying option 1
There was a problem hiding this comment.
I guess this is a bit much for only a log statement..
There was a problem hiding this comment.
Perhaps a compromise: We'll make this a ROS_INFO but the matches (which are much more verbose) a ROS_DEBUG?
There was a problem hiding this comment.
Yes, I think that is a good compromise :)
ct2034
added
backport
Stop flooding the terminal by default with all matches, switch to debug if desired (backport #364 to ros2-kilted)
…ug if desired (#364) (#613) * Stop flooding the terminal by default with all matches, switch to debug if desired * Put loggers back to INFO which are not in a loop or redundant with the initial log of the function * Log once per analyzer is ok --------- (cherry picked from commit 8fbd07d) Co-authored-by: Ferry Schoenmakers <MCFurry@users.noreply.github.com> Co-authored-by: Tim Clephas <tim.clephas@nobleo.nl>
Stop flooding the terminal by default with all matches, switch to debug if desired (backport #364 to ros2-jazzy)
3 participants
We noticed that when extending a ROS system with many analyzers, the terminal during startup is flooded with all the analyzer matches.
I reckon these can be debug logs that one can enable when desired.
(Example in the tests, since these require these stdout logs)