Tim Rozet in Bug 1470191 dixit:
"Ideally we want ODL logging to be part of systemd journaling."
This new (type Enhancement) issue is the umbrella to look into this:
* investigate technical feasibility (POC)
* understand if it needs upstream work (ODL / Karaf),
and if so, create new issues on respective upstream trackers, and link here
* link any work done related to this
I've noticed in an ODL Karaf distribution (built locally from an upstream current master = future Nitrogen release, based on Karaf 4) that there is an appender named 'syslog' in the etc/org.ops4j.pax.logging.cfg file (which is basically a Log4j v2 configuration used by Karaf, through some OPS4j's PAX Logging in the middle), using org.apache.log4j.net.SyslogAppender.
Isn't there a "thing" which translates stuff pushed into a syslog port (by SyslogAppender) into systemd journal, correctly translating events, with structure for e.g. stacktrace and all?
One would natively assume such a translator must exist - isn't there lots of existing old stuff pushing to syslog (like Log4j's SyslogAppender) which loads of people want to get into systemd journal, without everyone adjusting their apps?
If there is not, then I guess this boils down to us having to do integration work to get https://github.com/bwaldvogel/log4j-systemd-journal-appender into ODL, or probably much better, straight away upstream Karaf? I've just opened https://issues.apache.org/jira/browse/KARAF-5275 to first discuss this further over there (and in doing so and further investigating, realized that it actually probably needs to go into OPS4j's PAX Logging, first)...
> integration work to get https://github.com/bwaldvogel/log4j-systemd-journal-appender into ...
Janki has pointed out https://github.com/insideo/randomcoder-log4j-systemd-journal/ as an alternative, and I've spent a minute having a closer look into both of these, to conclude that bwaldvogel/log4j-systemd-journal-appender is the one to go with, because:
(1) it has both new Log4j2 as well as old Log4j v1 support, which is important because we are currently on Log4j v1 with Karaf 4.0.x, but will eventually get to Log4j2 on Karaf 4.1.x;
(2) it's available on Maven central (in both versions), whereas randomcoder's is only on Bintray (so for upstream OPS4j and Karaf integration that's no go);
(3) is a bit more configurable; e.g. we can choose whether or not to send say the ODL internal thread name into systemd journal, or not
(4) minor difference in mapping Log4j FATAL level (bwaldvogel LOG_CRIT, randomcoder LOG_EMERG via getSyslogEquivalent()), but as we use log4j directly only slf4j not which doesn't have FATAL directly (only via Marker, see FAQ) that's irrelevant
(5) bwaldvogel's has more stars and forks on GitHub than insideo's ;-) and more recent updates
Otherwise they are similar - both implemented via com.sun.jna.Library. The code even looks close enough to make me think that bwaldvogel may actually have been directly inspired by randomcoder's (e.g. normalize[Key]() method).