[systemd-devel] journald syslog forwarding

[Holger Winkelmann [TP]]

Hi,

>> upload sounds a bit of a batch process, but thats just cosmetic wording.
>> 
>> Having this in systems-journald and extend the forward to syslog config with the
>> target
>> host was our expectation anyway.

> 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 agree with your findings, and basically thats how the zmq journal gateway works as
well. And thanks to bring the "wait for network" up here, you would miss important
boot log entries here. 

Would the upload tool learn a new URL for this purpose i.e. syslog://<ip>:514 ?

>> > Initial plan was to implement the most straighforward syslog forwarding,
>> > so only the MESSAGE field would be sent.
>>  
>> it would be great to have at least the following format to send to syslog:
>> 
>> "<%pri%>%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name%
>> %procid% %msg%\n"
>> 
>> described as rsyslog configuration. All the meta infos are there IMHO.
> Yes. We just wouldn't go into "structured" syslog messages to carry other
> fields.

I agreed as well mapping then into the "struct syslog format" wold be a config
pain I assume. However the one we listed above should be there ?!?!... If people
correlating syslog messages on a central server, time, hostname etc. are meaningful.

Holger
-- 
Holger Winkelmann


email: holger.winkelmann at travelping.com