[FR] select the logger implementation without rebuilding

[fujitatomoya]

[FR] select the logger implementation without rebuilding

[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