I have a rsyslog-based log server and would like to know how I
can configure journalctl to send its logs to said log server.
5 thoughts on - Journalctl And Log Server
You don’t. You install rsyslog on your “client” server and set it up to forward as normal.
In the basic state, this just looks exactly like the traditional way. (In fact, you can even turn off persistent journald if you like.) Or, you can use ‘imjournal’ for more sophisticated integration if you like — see
<http://www.rsyslog.com/doc/imjournal.html>.
In fact in EL7 the default behaviour is no persistent journald since the logging is set to auto and there is no /var/log/journal …
The default behaviour is to have journald collect the logs and forward them all to rsyslog to then be stored on disk or filtered or forwarded just the same as in EL6 …
On a related note this does mean that if you want persistent journald logging you must remember to create that directory…
Is it me who have not had coffee yet or that assumes you have to have rsyslog installed in the machine running systemd/journald? For the sake of this discussion, let’s say that is not an option for whatever reason, so you must make journald talk to the rsyslog server. What would need to be done in both ends?
Now, let’s say we are trying to prove journald is superior to rsyslog, so we must not use rsyslog in this machine (only in the syslog server since it is up and has to deal with others)
That’s a bit like saying “you must make mysql talk to the apache webserver”. The journal has its own mechanism using systemd-journal-remote but that hasn’t been included in CentOS7 because its fairly new.
In this scenario you would set up systemd-journal-remote on the server in addition to rsyslog so syslog clients can keep using the rsyslog endpoint and journal client can use the journal-remote one. On the server you could then forward the data to the local rsyslog to have everything in one place/format.
The whole remote logging story is still pretty dodgy right now though so I would stick to rsyslog for now.
Regards,
Dennis
Oh, whoops. I’m living too far in the future over here. :)
5 thoughts on - Journalctl And Log Server
You don’t. You install rsyslog on your “client” server and set it up to forward as normal.
In the basic state, this just looks exactly like the traditional way. (In fact, you can even turn off persistent journald if you like.) Or, you can use ‘imjournal’ for more sophisticated integration if you like — see
<http://www.rsyslog.com/doc/imjournal.html>.
In fact in EL7 the default behaviour is no persistent journald since the logging is set to auto and there is no /var/log/journal …
The default behaviour is to have journald collect the logs and forward them all to rsyslog to then be stored on disk or filtered or forwarded just the same as in EL6 …
On a related note this does mean that if you want persistent journald logging you must remember to create that directory…
Is it me who have not had coffee yet or that assumes you have to have rsyslog installed in the machine running systemd/journald? For the sake of this discussion, let’s say that is not an option for whatever reason, so you must make journald talk to the rsyslog server. What would need to be done in both ends?
Now, let’s say we are trying to prove journald is superior to rsyslog, so we must not use rsyslog in this machine (only in the syslog server since it is up and has to deal with others)
That’s a bit like saying “you must make mysql talk to the apache webserver”. The journal has its own mechanism using systemd-journal-remote but that hasn’t been included in CentOS7 because its fairly new.
In this scenario you would set up systemd-journal-remote on the server in addition to rsyslog so syslog clients can keep using the rsyslog endpoint and journal client can use the journal-remote one. On the server you could then forward the data to the local rsyslog to have everything in one place/format.
The whole remote logging story is still pretty dodgy right now though so I would stick to rsyslog for now.
Regards,
Dennis
Oh, whoops. I’m living too far in the future over here. :)