On Tue, 10.12.13 12:16, Cecil Westerhof ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
