<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 12/11/2014 03:31 PM, Zbigniew Jędrzejewski-Szmek wrote: </div> <blockquote cite="mid:20141211153108.GE18247@in.waw.pl" type="cite"> <pre wrap="">The difference is in how the logs are accessed: if journald itself does the jobs, they would be forwarded "live". If anything else, the uploader would be a client which reads the files in /var/log/journal/. The are advantages to both solutions: the first one might be more robust if writing the logs fails or stops for whatever reason. The second one will probably send more logs, because sending of logs can be delayed until the network is up. In the second version, the uploader can also forward logs from other machines (containers). Now that I spelled it out, the second version seems nicer. </pre> </blockquote> I'm not quite following what you said there but I would actually think the former as in "forward it live" is better, just define a host and a port in journald.conf as well as perhaps the format of the logs being sent. native journal, bsd-syslog, json ( or not and just send it natively ) and perhaps the ability to send just specific journal types as in... system journal --> system.journal User journal --> user-x.journal Container journal --> container-x.journal etc. I personally dont think we should write any "clients" or uploaders other then perhaps a listener that accepts only native journal output being sent to it, and probably should rotate those files on tcp disconnects and stores those "machine/host files" under relevant journal path. We already have existing log solution like syslog-ng that natively reads, filters locally and forwards those filtered logs over the wire and or to a local ( running on the same host ) centralized syslog server which takes care of anything including and beyond simply sending the log over the wire... JBG </body> </html>