Bug 1475951 - ODL should log using systemd journal instead of into its own log files
ODL should log using systemd journal instead of into its own log files
Product: Red Hat OpenStack
Classification: Red Hat
Component: opendaylight (Show other bugs)
Unspecified Unspecified
medium Severity medium
: Upstream M2
: 13.0 (Queens)
Assigned To: Michael Vorburger
Itzik Brown
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2017-07-27 11:36 EDT by Michael Vorburger
Modified: 2018-02-19 09:19 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-02-19 09:19:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenDaylight Bug ODLPARENT-129 None None None 2017-11-03 12:54 EDT
Apache JIRA KARAF-5275 None None None 2017-08-09 09:29 EDT

  None (edit)
Description Michael Vorburger 2017-07-27 11:36:24 EDT
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 12:41:23 EDT
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 03:33:19 EDT
> 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.