syslog mit rsyslog über TCP weiterleiten, abgesichert durch eine Disk-Assisted Queue

Ziel

Sämtlichen lokalen Log-Verkehr eines rsyslog-Hosts per TCP an einen zentralen Collector weiterleiten. Ein lokaler Puffer hält die Meldungen auf der Festplatte vor, falls der Collector oder das Netzwerk nicht erreichbar ist, statt sie zu verwerfen.

Voraussetzungen

Root-Zugriff; rsyslog ist installiert und läuft (rsyslogd -v); Adresse und Port des Collectors sind bekannt; auf einem Dateisystem, in das der rsyslog-Benutzer schreiben darf, ist genügend Speicherplatz für das Spool-Verzeichnis frei.

Schritte

1. Die Standard-/etc/rsyslog.conf der Distributionen (Debian, Ubuntu, RHEL) bindet jede Datei in /etc/rsyslog.d/ ein, die auf *.conf passt, und zwar in der Sortierreihenfolge der Dateinamen; das Beispiel der Dokumentation verwendet selbst eine nummerierte Datei wie /etc/rsyslog.d/10-myapp.conf. Statt rsyslog.conf direkt zu bearbeiten, ein neues Drop-in anlegen, damit die Änderung isoliert bleibt und sich leicht entfernen lässt: /etc/rsyslog.d/60-forward.conf.
2. In dieser Datei eine Disk-Assisted Queue und eine Action definieren, die alles über TCP weiterleitet:

# queue files go to the workDirectory already set in rsyslog.conf
action(type="omfwd"
       target="collector.example.org" port="514" protocol="tcp"
       queue.type="LinkedList"
       queue.filename="fwd01"
       queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

queue.type="LinkedList" in Verbindung mit queue.filename ergibt eine Disk-Assisted Queue: Normalerweise liegt sie im Arbeitsspeicher und läuft in das Work-Verzeichnis auf die Festplatte über, sobald sie die High Watermark erreicht (Standard: 90 % von queue.size, das bei einer Action Queue standardmässig 1000 Meldungen beträgt). Mit queue.saveOnShutdown="on" werden zudem beim Herunterfahren die noch wartenden Meldungen gespeichert. action.resumeRetryCount="-1" bewirkt, dass die Weiterleitung unbegrenzt wiederholt wird, statt nach einer festen Zahl von Versuchen aufzugeben. 3. Das Work-Verzeichnis mit grep -ri workdirectory /etc/rsyslog.conf ermitteln (Debian/Ubuntu: /var/spool/rsyslog; RHEL: /var/lib/rsyslog) und nicht ein zweites Mal setzen. Sicherstellen, dass der Benutzer, unter dem rsyslogd läuft, dort schreiben darf und genügend freier Platz für die erwartete Ausfalldauer vorhanden ist; queue.maxDiskSpace begrenzt, wie viel Platz die Queue höchstens belegt. 4. Die Konfiguration prüfen, ohne den laufenden Daemon neu zu starten: rsyslogd -N1 -f /etc/rsyslog.conf führt laut der Option -N in rsyslogd(8) nur eine Konfigurationsprüfung durch; es gibt Fehler aus und startet kein Logging. 5. Die Änderung übernehmen: systemctl restart rsyslog. Ein Reload genügt nicht: Laut rsyslogd(8) veranlasst SIGHUP rsyslogd nur dazu, seine offenen Dateien zu schliessen; die Konfiguration wird nicht neu eingelesen. Ein Neustart des Dienstes ist kein Neustart des Systems. 6. Die Weiterleitung testen: Auf dem Quell-Host logger "forward test $(date -u +%FT%TZ)" ausführen und prüfen, ob die Meldung auf dem Collector eintrifft. Einen Ausfall simulieren, indem der Collector-Port mit einer Firewall-Regel blockiert wird. Dann mehr Meldungen erzeugen, als die High Watermark umfasst (z. B. 2000 logger-Aufrufe; eine Handvoll bleibt im Arbeitsspeicher), und bestätigen, dass im Work-Verzeichnis Queue-Dateien entstehen und sich nach Aufhebung der Blockade wieder leeren.

Erwartetes Ergebnis

rsyslogd -N1 meldet keine Fehler; Testmeldungen erreichen den Collector; während eines simulierten Ausfalls wachsen die Queue-Dateien im Work-Verzeichnis und werden gesendet, sobald die Verbindung wieder besteht. Im Log des Collectors entsteht über den Ausfallzeitraum hinaus keine Lücke.

Grenzen und Prüfbasis

Basiert auf der rsyslog-Dokumentation zu Include-Dateien, Queues und RainerScript-Queue-Parametern sowie auf rsyslogd(8). Zum Rückgängigmachen die Drop-in-Datei entfernen und rsyslog neu starten; im Work-Verzeichnis verbliebene Queue-Dateien können gelöscht werden, sobald die Queue abgearbeitet ist. Eine Queue mit unbegrenzten Wiederholungen und ohne Limit durch queue.maxDiskSpace kann bei einem langen Ausfall die Festplatte füllen – daher stets ein Limit setzen, das auf die Partition abgestimmt ist.