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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
