Erklärung rsyslog-client

Zeile für Zeile

*.*

Der klassische Selektor „alle Facilities, alle Prioritäten“. Es wird also wirklich jede Meldung weitergeleitet – von debug bis emerg. Einschränken ließe sich das z. B. mit *.info oder authpriv.*.

action(type="omfwd" …)

omfwd ist das Ausgangsmodul für die Weiterleitung über das Netz. Es ist fest eingebaut, muss also nicht geladen werden. Die neue action()-Syntax wird hier gebraucht, weil die alte Kurzform *.* @@192.168.1.10:514 keine Queue-Parameter kennt.

target="192.168.1.10" / port="514"

Adresse und Port des Logservers. Ein Hostname wäre auch möglich, eine IP erspart aber die Abhängigkeit von der Namensauflösung – gerade beim Booten oder wenn der DNS selbst Probleme meldet.

protocol="tcp"

Übertragung per TCP statt UDP. Nur damit ist die Queue überhaupt sinnvoll: rsyslog merkt bei TCP, wenn die Zustellung fehlschlägt. Bei UDP schickt es blind ins Netz und erfährt von einem Ausfall nichts.

Die Queue – der eigentliche Kern

queue.type="linkedlist"

Eine dynamisch wachsende Warteschlange im Arbeitsspeicher (verkettete Liste). Sie belegt nur so viel Speicher, wie gerade gebraucht wird – im Gegensatz zu fixedarray, das seinen Platz sofort reserviert. Ohne diesen Parameter läuft die Aktion in der Direct-Queue: jede Meldung wird sofort und synchron zugestellt, und ein hängender Server bremst das ganze System aus.

queue.filename="fwdqueue"

Macht daraus eine Disk-Assisted Queue. Läuft der Speicherpuffer voll, schreibt rsyslog die Meldungen unter diesem Namen nach /var/spool/rsyslog/ auf Platte. Der Name muss auf dem Host eindeutig sein, wenn mehrere Queues konfiguriert sind.

action.resumeRetryCount="-1"

Anzahl der Wiederholversuche nach einem Fehler; -1 heißt „unendlich oft“. Ohne das gibt rsyslog nach wenigen Versuchen auf und verwirft die Meldungen – der Logserver darf also beliebig lange weg sein (Reboot, Wartung), ohne dass etwas verlorengeht.

queue.saveOnShutdown="on"

Beim Beenden des Dienstes wird der noch nicht zugestellte Inhalt der Queue auf Platte geschrieben und beim nächsten Start wieder eingelesen. Ohne das wäre der Puffer nach einem Neustart des Clients weg.

Zusammenspiel

Fällt der Logserver aus, sammelt der Client die Meldungen im Speicher, ab einer gewissen Menge auf Platte, und probiert es endlos weiter. Kommt der Server zurück, wird der Rückstand automatisch nachgeliefert – in der ursprünglichen Reihenfolge, mit den Originalzeitstempeln.

Hinweise für die Praxis

• Lokale Kopie bleibt erhalten: Diese Aktion leitet nur weiter. Ohne stop schreiben die Standardregeln zusätzlich nach /var/log/…. Das ist meist erwünscht – bei einem Ausfall des Servers hat man dann immer noch die lokalen Logs.
• Platzbedarf begrenzen: Standardmäßig darf die Disk-Queue erheblich wachsen. Bei knappem Plattenplatz zusätzlich queue.maxDiskSpace="1g" und queue.maxFileSize="16m" setzen.
• Spool-Verzeichnis prüfen: $WorkDirectory /var/spool/rsyslog muss existieren und dem rsyslog-Benutzer gehören, sonst schlägt das Auslagern still fehl.
• Test: Mit logger -t test "Hallo Logserver" eine Meldung erzeugen und auf dem Server unter /var/log/hosts/<client>/test.log nachsehen.
• Ausfall simulieren: Auf dem Server rsyslog stoppen, auf dem Client weiter Meldungen erzeugen, Server wieder starten – die Meldungen kommen nach. Gutes Übungsszenario im Kurs.
• Sicherheit: Auch hier gilt: unverschlüsselt und ohne Authentisierung. Über unsichere Strecken TLS (StreamDriver) oder RELP verwenden.