On 12/11/2014 03:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
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.
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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
