Syslog

Entstehung und Beteiligte

Syslog wurde in den 1980er-Jahren von Eric Allman als Bestandteil von Sendmail entwickelt. Weil das einfache Format von vielen Systemen übernommen wurde, dokumentierte die IETF es später; RFC 5424 standardisierte 2009 ein modernes Nachrichtenformat.

Welches Problem sollte gelöst werden?

Programme und Netzwerkgeräte sollten Ereignisse an eine zentrale Stelle senden können, ohne für jede Anwendung ein eigenes Protokoll zu bauen.

Technische Hürden und Lösungen

Klassisches UDP-Syslog verliert Nachrichten und besitzt keine Authentifizierung. Unterschiedliche Zeitstempel und freie Textformate erschweren Auswertung. TCP, TLS, strukturierte Daten und zentrale Zeitsynchronisierung verbessern Zuverlässigkeit.

Standardisierung und Einordnung

Monitoring entwickelte sich vom einfachen Prüfen erreichbarer Geräte zu einer eigenen Disziplin aus Metriken, Ereignissen, Protokollen und Traces. Die zentrale Schwierigkeit besteht nicht im Sammeln möglichst vieler Daten, sondern im Erkennen relevanter Abweichungen. Zeitstempel, eindeutige Identitäten, Aufbewahrung, Normalisierung und sinnvoll gesetzte Alarmgrenzen entscheiden darüber, ob Messdaten im Störungsfall helfen.

Technik im praktischen Betrieb

Ein Messwert benötigt Kontext: Einheit, Quelle, Intervall, Aggregation und erwarteten Normalbereich. Durchschnittswerte können kurze Spitzen verdecken, Maximalwerte kleine Ausreißer überbetonen. Aufbewahrung und Auflösung sollten zum Diagnoseziel passen. Alarme müssen einen klaren Besitzer, eine Handlungsanweisung und eine Eskalation besitzen. Regelmäßige Tests mit absichtlich ausgelösten Fehlern zeigen, ob Benachrichtigung, Bereitschaft und Runbook wirklich funktionieren.

Warum das Thema heute noch relevant ist

Historische Daten schaffen erst dann Wert, wenn sie vergleichbar bleiben. Änderungen an Geräten, Namen, Intervallen oder Messdefinitionen müssen deshalb nachvollziehbar sein. Langfristige Trends beantworten Kapazitätsfragen, detaillierte kurze Daten helfen bei Störungen. Beide Ziele verlangen unterschiedliche Auflösung. Monitoring ist zugleich Teil der Beweiskette: Ohne unabhängige Zeit, unveränderte Logs und bekannte Datenlücken lässt sich nach einem Vorfall nur schwer unterscheiden, was tatsächlich geschah und was lediglich vermutet wird.

Daten und Meilensteine

• Syslog stammt ursprünglich aus Sendmail.
• Facility beschreibt Quelle, Severity die Dringlichkeit.
• UDP 514 ist klassisch, TLS-Syslog nutzt häufig TCP 6514.
• RFC 5424 definiert ein standardisiertes modernes Format.

Was ist Syslog?

Syslog (RFC 5424) ist das Standard-Logging-Protokoll für Unix/Linux-Systeme, Netzwerkgeräte und Anwendungen. Es definiert Format und Transport von Log-Meldungen. Jede Syslog-Nachricht enthält: Timestamp, Hostname, Facility (Quelle), Severity (Schweregrad), Process und Message.

Zentraler Syslog-Server (rsyslog, syslog-ng) sammelt Logs von allen Quellen. Dies ist essentiell für Fehlerdiagnose, Security-Analyse und Compliance (Logs müssen oft 6-12 Monate aufbewahrt werden).

Facility und Severity

Facility-Codes kategorisieren die Log-Quelle: 0=kern, 1=user, 4=auth, 5=syslog, 16-23=local0-local7 (für eigene Anwendungen).

Severity-Level (0-7, wichtig zu kennen):

• 0: Emergency (emerg) – System nicht nutzbar
• 1: Alert – sofortige Aktion erforderlich
• 2: Critical – kritische Bedingung
• 3: Error – Fehlerbedingung
• 4: Warning – Warnung
• 5: Notice – normale, aber wichtige Bedingung
• 6: Informational – Informationsmeldungen
• 7: Debug – Debug-Level

Log-Management und SIEM

Für größere Umgebungen reicht eine Textdatei nicht aus. Log-Management-Systeme (ELK-Stack: Elasticsearch, Logstash, Kibana), Graylog oder Splunk indizieren Logs für schnelle Suche, Visualisierung und Alerting.

Transport: Klassisch UDP Port 514 (kein Verlustschutz), TCP 514 für Zuverlässigkeit, TLS (Port 6514) für verschlüsselten Transport. Structured Logging (JSON) vereinfacht Parsing erheblich.