Make systemd journal persistent | remove rsyslog (by default)

Fiedler Roman Roman.Fiedler at ait.ac.at
Wed Jan 11 09:04:45 UTC 2017


> From: ubuntu-devel-bounces at lists.ubuntu.com [mailto:ubuntu-devel-
>
> Jamie Strandboge [2017-01-10 16:27 -0600]:
> > Remote logging. Rsyslog is far superior in this regard. Granted,
> remote logging
> > is not enabled by default but it is a requirement in many
> environments.
>
> The systemd-journal-remote package does provide the necessary tools and is
> reasonably flexible (push or pull, builtin https or using arbitrary ports 
> which
> you e. g.  could forward through ssh). It might not be as flexible as
> rsyslog, but as one needs to set up remote logging manually anyway, you 
> always
> have the possibility of picking rsyslog, journal, or even something else.

I have done a POC with systemd-journal-remote yet, but that sounds quite good.
In our production environment following features should be supported also by
Rsyslog replacements to support current usecases and ease gradual rollout:

1) rsyslog RELP mode (reliable remote transport) - reduces probability for 
lost messages during network maintenance, e.g. statefull firewall restarts 
without conntrack failover.

2) Remote log data caching on network downtimes - data should be transmitted 
when network up again

3) Cascading operation: branch offices or guest perform remote logging to a 
nearby concentrator, only the concentrator has to be granted off-site access 
in firewall

4) TLS support with own CA - each new machine will get a new certificate from 
deployment system, central logging should accept traffic from all those 
machines with valid certificate automatically (eases automatic rollout)

5) rsyslog/system hybrids: in early phase there will be e.g. some old rsyslog 
based LXC containers forwarding logs to systemd-only hosts and perhaps also 
vice versa.

6) Streams > 10GB logs/day should not cause any troubles, log data losses.

7) Integration with SIEMs or logmanagement solutions, e.g. graylog.

Perhaps not all those features are possible/sensible to have 
systemd-journal-remote. In that case another requirement could arise:

8) Allow local rsyslog/systemd-journal-remote combination: systemd forwards 
the logs to a local rsyslog (which might also process other remote data from 
requirement 3), and all the really remote forwarding will happen using 
old-style rsyslog. Of course this would require maintenance of automation 
scripts for setup/automatic configuration of both rsyslog/systemd in various 
flavours (host/LXC-guest, Trusty/Xenial/CentOS)


I put it on my list, that I have to do a ~3 machine POC with 
systemd-journal-remote only setup to check all those requirements. As rsyslog 
is not completely trouble-free, this might help cut down costs in the long 
run.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6372 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20170111/7414c28a/attachment.bin>


More information about the Ubuntu-devel-discuss mailing list