[FR] select the logger implementation without rebuilding

[fujitatomoya]

Feature request

Feature description

Currently there is no way to select the logging backend without building rcl.
This is because that when building rcl, we must choose the logging implementation to be used.

In default rcl_logging_spdlog is selected if RCL_LOGGING_IMPLEMENTATION is not set.
But we can change it with RCL_LOGGING_IMPLEMENTATION and available logging backend library.

e.g rcl_logging_noop

export RCL_LOGGING_IMPLEMENTATION=rcl_logging_noop
colcon build --symlink-install --cmake-clean-cache --packages-select rcl_logging_noop rcl

and, no log files are generated with rcl_logging_noop

root@tomoyafujita:~/ros2_ws/colcon_ws# ros2 run demo_nodes_cpp talker
[INFO] [1724349615.489636579] [talker]: Publishing: 'Hello World: 1'
[INFO] [1724349616.489588912] [talker]: Publishing: 'Hello World: 2'
[INFO] [1724349617.489610598] [talker]: Publishing: 'Hello World: 3'
[INFO] [1724349618.489512697] [talker]: Publishing: 'Hello World: 4'
...
root@tomoyafujita:~/.ros/log# ls

This generates the constraint that whole system needs to use only specified logging backend in this workspace.
It would be nice if we can build the logger backend libraries, and select the logging backend when the program starts.

Implementation considerations

Current related code is,

rcl/rcl/cmake/get_default_rcl_logging_implementation.cmake

Lines 26 to 34 in dcfe9ba

	# if logging implementation already specified or RCL_LOGGING_IMPLEMENTATION environment variable
	# is set then use that, otherwise default to using rcl_logging_noop
	if(NOT "${RCL_LOGGING_IMPLEMENTATION}" STREQUAL "")
	set(_logging_implementation "${RCL_LOGGING_IMPLEMENTATION}")
	elseif(NOT "$ENV{RCL_LOGGING_IMPLEMENTATION}" STREQUAL "")
	set(_logging_implementation "$ENV{RCL_LOGGING_IMPLEMENTATION}")
	else()
	set(_logging_implementation rcl_logging_spdlog)
	endif()

Probably we can escalate RCL_LOGGING_IMPLEMENTATION like how RMW_IMPLEMENTATION works to select the rmw implementation when executing programs.

[clalancette]

I'll state upfront that I'm not against this feature.

But are there any practical uses for it? While I think that our logging subsystem has a number of problems, swapping out the disk logging backend at runtime doesn't seem to be one of them. So I'd like to hear about a practical use before we spend time on it.

[fujitatomoya]

@clalancette

the use case (not production yet) that i have off the top of my head, to support 2 (or multiple) logger backend in the same system.

• one could be default spdlog, that just stores the logging files in specific file system. (on-system log just in case.)
• we have proprietary in-memory logger backend, some performance critical application uses. (once the memory chunk is full, squash those into the file system and send it to the cloud or something.)
• not all, but some nodes are system application, so that we want to send the log data via logging data pipeline (such as rsyslog, FluentBit) to entire system observability to collect and aggregate the log data, and give the feedback to the system.

note: i am spending a couple of days for rcl_logging_syslog (forwarded to FluentBit), so i can share more details about this. I think i can disclose the source code with some documentation in this weekend. (or hopefully today 😄 )

[fujitatomoya]

@clalancette i developed some PoC based on syslog and support FluentBit, please see overview https://github.com/fujitatomoya/rcl_logging_syslog