[systemd-devel] Logging in an enterprise environment

[Cecil Westerhof]

On 12/10/2013 07:16 PM, Lennart Poettering wrote:
>> As I understand it, journald is mend to log locally. Two methods to
>> log centrally are, if I have understand it correctly:
>> - mounting and merging through NFS
>> - systemd-journal-gateway
>>
>> Whereby the first would be the preferred method.
>>
>> That would not be always acceptable for our clients. As I understood
>> it there are environments where now 700+ systems are monitored from
>> one log server. Using NFS for this would ask to much resources. I
>> think that systemd-journal-gateway also would not be very handy for
>> this because it is a pulling solution.
>>
>> To make things even more complicated: sometimes they want no local
>> logging at all, all logging should be done remotely, so that not one
>> user on the system could read the logs.
>>
>> Would something like this be possible to implement? If so, how much
>> work would it be? Probably our company would be prepared to let
>> programmers write this functionality.
>
> Journald's primary job is local logging, for complex logging setups we
> recommend installing a logging services like rsyslog.

Would you not loose some of the advantages of journald this way? I 
understand that with using imjournal in rsyslog this probably could 
mostly be circumvented.

I have seen that the local logging can be disabled with:
     Storage=none


> You can to centralized logging with the journal too, by simply making
> the journal files you want to look at accessible on the same
> machine. This could be done via NFS sharing, or by copying them to a
> central host via rsync or scp or even ftp, whatever you
> prefer. "journalctl -m" will then be able to coalesce them on display.

NFS is not acceptable I am told, but I'll inquire about the other 
possibilities.

By the way: is just copying possible? What if an event is logged at the 
moment the copy is done?


> Eventually journald should provide you with both a pull and a push
> model, however it currently onyl supports a pull model. Note that for

Where can I information about that, or do you mean copying the files?


> large setups a pull model is actually the more deseriable since the
> centralized logging serve can then pull logs out of the cluster on its
> own terms and schedule. Such a setup in push scenario might make the log
> server vulnerable to flooding when some event happens across the whole
> cluster (example: the cluster networked is portscanned, or power state
> changes for all cluster machines at the same time).

Sounds reasonable.