Betrieb & Monitoring
Syslog
Syslog ist der etablierte Standard für Logmeldungen: Systeme senden Logs mit Facility und Severity an einen zentralen Sammler (rsyslog, syslog-ng).
- Standard für Logmeldungen
- RFC 5424 (strukturiert)
- TLS, RELP (zuverlässig)
- zentrales Logging
- rsyslog, syslog-ng, journald
Syslog ist der etablierte Standard für Ereignis- und Logmeldungen. Systeme und Dienste klassifizieren jede Meldung nach Facility (Quelle) und Severity (Schweregrad) und senden sie an einen lokalen oder zentralen Sammler, die Grundlage für einheitliches Logging.
Dieser Artikel erklärt die Formate (BSD-Syslog gegenüber dem modernen RFC 5424), die Transportwege samt TLS und RELP, die gängigen Implementierungen rsyslog, syslog-ng und journald sowie die Grenzen von Syslog.
1. Formate: RFC 3164 und RFC 5424
Das alte BSD-Syslog (RFC 3164) beschrieb nur den historisch gewachsenen Zustand und kennt kein maschinenlesbares Format. Der moderne Standard RFC 5424 bringt definierte Zeitstempel, klare Felder und ein Feld für strukturierte Daten (Key-Value), was das Parsen erheblich erleichtert. Die Priorität ergibt sich aus Facility und Severity (Severity 0 = Emergency bis 7 = Debug).
2. Transport: UDP, TCP, TLS, RELP
Klassisch läuft Syslog über UDP (Port 514), ohne Quittung und damit verlustanfällig. TCP ist zuverlässiger, TLS (RFC 5425) verschlüsselt den Transport. Für garantierte Zustellung gibt es RELP (Reliable Event Logging Protocol): Der Empfänger quittiert jede Nachricht auf Anwendungsebene, sodass auch bei Verbindungsabbruch nichts verloren geht.
Nacktes UDP-Syslog ist bequem, aber blind: Geht eine Meldung verloren, merkt es niemand. Für ernsthaftes zentrales Logging gehören TLS oder RELP zum Standard.
3. Implementierungen
rsyslog (vom RFC-5424-Autor) ist auf vielen Linux-Distributionen der Standard-Daemon, modular und RELP-fähig. syslog-ng bietet eine mächtige Filtersprache und viele Ausgabeziele. systemd-journald sammelt Logs lokal in einem binären, indizierten Format und leitet sie typischerweise an rsyslog oder syslog-ng zur zentralen Weiterverarbeitung weiter.
4. Grenzen
Syslog ist auf Log-Events beschränkt, Metriken und Traces gehören nicht dazu. Auch mit RFC 5424 bleibt der eigentliche Meldungstext freier Text ohne erzwungenes Schema, sodass weitergehendes Parsen anwendungsspezifische Regeln braucht. Für Sammlung, Transformation und Weiterleitung in Backends ergänzt man daher moderne Log-Shipper.
5. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Universeller, überall unterstützter Logging-Standard | MESSAGE bleibt freier Text; kein erzwungenes Schema |
| RFC 5424 mit strukturierten Daten; TLS und RELP für sicheren/zuverlässigen Transport | UDP-Standardtransport verlustanfällig und unverschlüsselt |
| Ausgereifte Implementierungen (rsyslog, syslog-ng, journald) | Nur Logs (keine Metriken/Traces); Weitertransport per Shipper nötig |
Häufige Fragen zu Syslog
Beide sind ausgereift. rsyslog ist auf vielen Distributionen Standard, sehr verbreitet und RELP-fähig. syslog-ng punktet mit einer besonders mächtigen Filter- und Routing-Sprache und vielen Ausgabezielen. Für zuverlässigen Transport unterstützen beide TLS, rsyslog zusätzlich RELP.
Syslog ist die Sammel- und Transportebene. Ein SIEM (etwa Wazuh) übernimmt Korrelation, Alerting und Aufbewahrung. Üblich ist: Syslog (rsyslog/syslog-ng) sammelt, ein Log-Shipper transformiert und leitet weiter, das SIEM oder ein Such-Backend wertet aus.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Syslog im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.