Zentrales Logging mit rsyslog: Logs mehrerer Server konsolidieren

1. Warum verteilte Logs im Ernstfall zum Problem werden

In einer typischen Magento Infrastruktur mit mehreren Applikationsservern hinter einem Loadbalancer entstehen Logs an vielen verschiedenen Stellen gleichzeitig: Nginx Access Logs auf jedem Frontend, PHP-FPM Error Logs auf jedem App-Server, dazu Datenbank- und Cache-Logs auf separaten Maschinen. Wenn ein Kunde einen Fehler meldet, weiß niemand vorab, auf welchem der Server die relevante Zeile tatsächlich liegt, und ein manuelles Durchsuchen von vier oder fünf Servern per SSH kostet in einem Vorfall wertvolle Zeit.

Zentrales Logging verschiebt diesen Aufwand von der Suchphase in die Sammelphase: Statt im Ernstfall auf jedem Server einzeln nach der passenden Zeitmarke zu suchen, liegen alle Log Zeilen bereits chronologisch sortiert an einem Ort vor. rsyslog eignet sich dafür besonders gut, weil es auf praktisch jeder Linux Distribution bereits als Standard Syslog Daemon installiert ist und weder ein zusätzliches Agenten Deployment noch eine externe Abhängigkeit benötigt, um als Sammelstelle zu fungieren.

2. Die Modul Architektur von rsyslog verstehen

rsyslog ist intern strikt in Input, Parser, Filter und Output Module aufgeteilt, die über eine Verarbeitungspipeline miteinander verbunden werden. Input Module, deren Namen mit im beginnen, nehmen Nachrichten entgegen, etwa imuxsock für den lokalen Unix Socket, imjournal für den Import aus dem systemd Journal, oder imtcp und imudp für Nachrichten, die über das Netzwerk eintreffen.

Output Module, deren Namen mit om beginnen, entscheiden, was mit einer Nachricht am Ende der Pipeline passiert. omfile schreibt in lokale Dateien, omfwd leitet Nachrichten an einen anderen Syslog Server weiter, und spezialisierte Module wie omelasticsearch senden direkt an externe Systeme. Zwischen Input und Output sitzen Rulesets und Warteschlangen, die bestimmen, welche Nachricht welchen Weg durch die Pipeline nimmt.

# Aktuell geladene rsyslog Konfiguration validieren, ohne den Daemon zu starten
rsyslogd -N1

# Aktive Module und deren Reihenfolge aus der Konfiguration extrahieren
grep -r "module(load=" /etc/rsyslog.conf /etc/rsyslog.d/

3. Einen zentralen rsyslog Server einrichten

Der zentrale Server benötigt zunächst ein aktiviertes Input Modul für eingehende Netzwerkverbindungen. Für TCP ist das imtcp, das im Gegensatz zu UDP eine zuverlässige, verbindungsorientierte Zustellung garantiert und deshalb für produktives zentrales Logging fast immer die richtige Wahl ist, weil einzelne UDP Pakete bei Netzwerklast stillschweigend verloren gehen können.

Damit die eingehenden Logs nicht alle in einer einzigen Datei landen, definiert eine Template Direktive den Zieldateipfad dynamisch anhand von Hostname und Programmname der jeweiligen Nachricht. So entsteht pro sendendem Server automatisch eine eigene, klar benannte Verzeichnisstruktur, ohne dass jeder Client einzeln konfiguriert werden muss.

# /etc/rsyslog.d/10-central-receiver.conf auf dem zentralen Server
module(load="imtcp")
input(type="imtcp" port="514" streamdriver.mode="0")

template(name="PerHostLog" type="string"
  string="/var/log/central/%HOSTNAME%/%programname%.log")

if $inputname == "imtcp" then {
  action(type="omfile" dynaFile="PerHostLog")
  stop
}

4. Clients für die Weiterleitung an den zentralen Server einrichten

Auf jedem Applikationsserver reicht eine kurze Zusatzkonfiguration, die alle lokal empfangenen Nachrichten zusätzlich über omfwd an den zentralen Server weiterleitet. Wichtig ist die Reihenfolge der Actions: Die Weiterleitung sollte vor einer eventuellen lokalen Filterung stehen, damit auch Nachrichten, die lokal verworfen werden, zentral erhalten bleiben.

rsyslog puffert ausgehende Nachrichten standardmäßig im Arbeitsspeicher. Bei einer kurzzeitigen Netzwerkunterbrechung zum zentralen Server gehen diese Nachrichten dadurch verloren, sobald der Puffer voll läuft. Für produktive Umgebungen empfiehlt sich deshalb eine disk unterstützte Warteschlange, die Nachrichten bei Bedarf temporär auf die lokale Festplatte auslagert, statt sie zu verwerfen.

# /etc/rsyslog.d/60-forward-central.conf auf jedem Applikationsserver
action(type="omfwd"
  target="log-central.internal" port="514" protocol="tcp"
  queue.type="LinkedList"
  queue.filename="fwd_central"
  queue.maxdiskspace="1g"
  queue.saveonshutdown="on"
  action.resumeRetryCount="-1")

5. TLS Verschlüsselung für den Log Transport aktivieren

Unverschlüsseltes Syslog über das Netzwerk bedeutet, dass Log Inhalte, darunter potenziell Session-IDs, IP-Adressen oder Fehlerdetails aus PHP-Stacktraces, im Klartext über das Netz laufen. rsyslog unterstützt TLS über den GnuTLS oder OpenSSL Stream Treiber und verschlüsselt die Verbindung zwischen Client und zentralem Server vollständig, inklusive optionaler Zertifikatsprüfung auf beiden Seiten.

Für den produktiven Einsatz empfiehlt sich eine eigene kleine Zertifizierungsstelle, deren Zertifikat auf allen beteiligten Servern hinterlegt wird. Der zentrale Server präsentiert ein Serverzertifikat, jeder Client validiert dieses gegen das CA-Zertifikat, und optional verlangt der Server umgekehrt ein gültiges Client Zertifikat, bevor er Verbindungen überhaupt annimmt.

# Serverseitig: TLS erzwingen und Client Zertifikate verlangen
module(load="imtcp"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name")
global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem")
input(type="imtcp" port="6514")

6. Vergleich zu journald Forwarding

Alternativ zu rsyslog bietet systemd mit systemd-journal-upload und systemd-journal-remote einen eigenen Weg, Journal Einträge über HTTP oder HTTPS an einen zentralen Server zu übertragen. Der Vorteil liegt in der nativen Integration mit strukturierten Journal Feldern, die als JSON übertragen werden und dabei zusätzliche Metadaten wie Boot-ID oder Unit-Namen behalten, die im klassischen Syslog Format verloren gehen.

Der Nachteil ist die geringere Verbreitung und Reife im Vergleich zu rsyslog: Weniger Distributionen aktivieren die Journal Remote Pakete standardmäßig, die Konfiguration über HTTPS Zertifikate ist weniger dokumentiert, und die Filterfähigkeiten am zentralen Empfänger sind eingeschränkter als das flexible Ruleset System von rsyslog. In gemischten Umgebungen mit Nginx, PHP-FPM und älteren Anwendungen, die klassisch nach Syslog schreiben, bleibt rsyslog deshalb meist die pragmatischere Wahl.

7. Praxisbeispiel: Nginx und PHP-FPM Logs zentralisieren

Nginx und PHP-FPM schreiben standardmäßig in lokale Dateien statt direkt nach Syslog. Um diese Logs in die zentrale Sammlung einzubeziehen, überwacht imfile die entsprechenden Dateien wie tail -f und speist neue Zeilen als Syslog Nachrichten in die rsyslog Pipeline ein, inklusive Zustands Tracking, damit nach einem Neustart kein Inhalt doppelt eingelesen wird.

Für die spätere Auswertung lohnt es sich, Nginx auf ein strukturiertes JSON Log Format umzustellen, statt das Standardformat zu verwenden. So lassen sich Statuscode, Request-Zeit und Upstream-Antwortzeit direkt als durchsuchbare Felder weiterverarbeiten, statt sie später mit fehleranfälligen regulären Ausdrücken aus einer Textzeile zu extrahieren.

# /etc/rsyslog.d/20-nginx-phpfpm-input.conf
module(load="imfile")

input(type="imfile"
  File="/var/log/nginx/access.log"
  Tag="nginx-access"
  Severity="info"
  Facility="local1")

input(type="imfile"
  File="/var/log/php-fpm/www-error.log"
  Tag="php-fpm"
  Severity="err"
  Facility="local2")

8. Performance und Warteschlangen Tuning bei hohem Log Aufkommen

Bei mehreren tausend Requests pro Sekunde auf einem Magento Shop kann das Log Volumen selbst zu einer spürbaren Last werden. rsyslog verarbeitet Nachrichten standardmäßig in mehreren parallelen Worker-Threads pro Warteschlange, deren Anzahl sich über queue.workerThreads anpassen lässt, wenn die Standardkonfiguration bei Lastspitzen nicht mehr mithält.

Ein weiterer wichtiger Hebel ist Rate-Limiting direkt am Input, um fehlerhafte Anwendungen zu bremsen, die in einer Schleife tausende identische Fehlermeldungen pro Sekunde erzeugen. Ohne Begrenzung kann eine einzelne fehlerhafte Anwendung sonst die gesamte zentrale Logging Infrastruktur überlasten und damit auch die Sichtbarkeit auf andere, tatsächlich relevante Fehler verschlechtern.

# Worker Threads erhöhen und Rate Limiting pro Absender aktivieren
main_queue(queue.workerThreads="4" queue.dequeueBatchSize="1000")

input(type="imtcp" port="514"
  ratelimit.interval="10"
  ratelimit.burst="2000")

9. Best Practices und Troubleshooting im Alltag

Vor jeder Änderung an der Konfiguration lohnt sich ein Testlauf mit rsyslogd -N1, der Syntaxfehler ohne einen echten Neustart des Daemons aufdeckt. Für den Verbindungstest zwischen Client und zentralem Server eignet sich logger, das eine einzelne Testnachricht über den lokalen Syslog Socket sendet und sich auf dem zentralen Server sofort in der erwarteten Zieldatei nachverfolgen lässt.

Firewall Regeln sind eine häufige Fehlerquelle: Der Port des zentralen Servers muss explizit für die Applikationsserver freigegeben sein, üblicherweise 514 für unverschlüsselte Verbindungen und ein separater Port wie 6514 für TLS, damit beide Betriebsarten sauber getrennt bleiben und ein versehentlich unverschlüsselter Client nicht unbemerkt Klartext über das Netz sendet.

Dokumentation zahlt sich hier besonders aus: Ein kurzer Überblick, welcher Server welche Facility und welchen Tag verwendet, erspart neuen Teammitgliedern das mühsame Rückwärtsermitteln der Konfiguration aus den bereits gesammelten Logs.

10. Zusammenfassung

11. FAQ: Zentrales rsyslog Logging