journald-Weiterleitung und zentrale Log-Sammlung: ForwardToSyslog, systemd-journal-upload/-remote und Rate Limits

Ziel

Journal-Einträge sollen einen Host verlassen, entweder indem sie an den lokalen Syslog-Stack übergeben werden (für die Weiterleitung per rsyslog) oder indem sie direkt an einen entfernten Journal-Collector gesendet werden. Dabei dürfen keine Einträge unbemerkt durch den internen Rate Limiter von journald verloren gehen.

Voraussetzungen

Root-Zugriff; systemd, bei direktem Versand mit installierten Paketen für systemd-journal-upload und systemd-journal-remote; bei HTTPS ein Zertifikatspaar (die Werkzeuge unterstützen auch einfaches HTTP, das über ein nicht vertrauenswürdiges Netzwerk jedoch nicht empfohlen wird).

Schritte

1. Um eine bestehende rsyslog-/Syslog-Pipeline zu speisen, in /etc/systemd/journald.conf oder in einer Drop-in-Datei unter /etc/systemd/journald.conf.d/ ForwardToSyslog=yes setzen. Laut journald.conf(5) reicht journald dann jeden Eintrag an den klassischen Syslog-Socket weiter; das rsyslog-Modul imuxsock übernimmt ihn wie jede andere Syslog-Quelle. Upstream ist der Standardwert no; Debian und Ubuntu patchen ihn auf yes. Das rsyslog von RHEL liest das Journal direkt mit imjournal, dort ist keine Änderung nötig.
2. Für den direkten Versand von Journal-Daten den Sender konfigurieren: In /etc/systemd/journal-upload.conf wird gemäss journal-upload.conf(5) URL=https://collector.example.org:19532 gesetzt. Anschliessend systemd-journal-upload.service starten und aktivieren. Laut Beschreibung lädt dieser Dienst Journal-Einträge an die mit --url=/URL= angegebene Adresse hoch, liest dazu aus den lokalen Journal-Dateien und sendet neue Einträge laufend weiter, sobald sie entstehen.
3. Auf dem Collector systemd-journal-remote.socket aktivieren (Standardport 19532). systemd-journal-remote.service empfängt Journal-Daten in dem in der eigenen Man-Page beschriebenen Journal-Export-Format und schreibt sie in Journal-Dateien unter /var/log/journal/remote/. Schlüssel und Zertifikat für TLS werden in /etc/systemd/journal-remote.conf konfiguriert (ServerKeyFile=, ServerCertificateFile=, TrustedCertificateFile=).
4. Bevor auf die Vollständigkeit eines der beiden Wege vertraut wird, den journald-eigenen Rate Limiter prüfen. Laut journald.conf(5) gilt für RateLimitIntervalSec= und RateLimitBurst=: Protokolliert ein Dienst innerhalb von RateLimitIntervalSec= mehr als RateLimitBurst= Meldungen (Standard: 10000 Meldungen in 30 Sekunden, hochskaliert mit einem Faktor, der vom freien Journal-Speicherplatz abhängt), werden weitere Meldungen dieses Dienstes innerhalb des Intervalls verworfen; journald schreibt dann einen Eintrag "Suppressed N messages from <unit>". Verworfene Einträge erreichen keinen Weiterleitungsweg, weder lokal noch remote. Bei Diensten, die bei Störungen voraussichtlich viel protokollieren, den Burst-Wert erhöhen, auf 0 setzen (deaktiviert) oder pro Unit mit LogRateLimitIntervalSec=/LogRateLimitBurst= überschreiben.
5. Änderungen übernehmen: systemctl restart systemd-journald für journald.conf, systemctl restart systemd-journal-upload für journal-upload.conf.

Erwartetes Ergebnis

journalctl -u systemd-journal-upload -f zeigt keine wiederholten Verbindungsfehler; auf dem Collector zeigt journalctl -D /var/log/journal/remote --list-boots Einträge mit den Boot-IDs des entfernten Hosts.

Grenzen und Prüfbasis

Grundlage sind journald.conf(5), journal-upload.conf(5), systemd-journal-upload.service(8) und systemd-journal-remote.service(8). Zum Rückgängigmachen die Unit stoppen und deaktivieren und die Drop-in-Datei entfernen. Ein Dienst mit hohem Log-Aufkommen, der das Rate Limit erreicht, hinterlässt Lücken sowohl an der Quelle als auch auf jedem entfernten Collector. Fehlen Einträge, zuerst im Journal nach "Suppressed" suchen, statt ein Netzwerkproblem anzunehmen.