[systemd-devel] journald syslog forwarding

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 11, 2014 at 04:09:54PM +0000, "Jóhann B. Guðmundsson" wrote:
> 
> 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, ju
Journal carries messages from the initramfs. We cannot send them from
the initramfs, unless we bring up the network then, which we don't want
to do just for this purpose. But those messages are stored in /run/log,
and then flushed to /var/log, and the uploader tool can forward them
after the network is established.

> 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...
I don't think this is a good idea. rsyslog and friends already do
such forwarding quite well. We should just aim to be simple replacement
for the common case where RFC5424 is enough.

Zbyszek

> 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