[systemd-devel] Logging in an enterprise environment
Lennart Poettering
lennart at poettering.net
Tue Dec 10 10:16:08 PST 2013
On Tue, 10.12.13 12:16, Cecil Westerhof (Cecil.Westerhof at Snow.nl) wrote:
> After giving a presentation about systemd/journald I am seen as the
> expert, so they come to me with the challenges they see.
>
> 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.
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.
Eventually journald should provide you with both a pull and a push
model, however it currently onyl supports a pull model. Note that for
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).
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list