Bug 1475951 - ODL should log using systemd journal instead of into its own log files
Summary: ODL should log using systemd journal instead of into its own log files
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: opendaylight
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: Upstream M2
: 13.0 (Queens)
Assignee: Michael Vorburger
QA Contact: Itzik Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2017-07-27 15:36 UTC by Michael Vorburger
Modified: 2018-02-19 14:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-02-19 14:19:36 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Apache JIRA KARAF-5275 None None None 2017-08-09 13:29:33 UTC
OpenDaylight Bug ODLPARENT-129 None None None 2017-11-03 16:54:36 UTC

Description Michael Vorburger 2017-07-27 15:36:24 UTC
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

* ....

Comment 1 Michael Vorburger 2017-07-27 16:41:23 UTC
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)...

Comment 2 Michael Vorburger 2017-08-11 07:33:19 UTC
> 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).

Note You need to log in before you can comment on or make changes to this bug.