Syslog Troubleshooting: Logs kommen nicht an – die Checkliste

Syslog Troubleshooting ist eine der wichtigsten Disziplinen im täglichen IT-Betrieb, weil zentrale Logs die Grundlage für Fehleranalyse, Security Monitoring und Compliance sind. Wenn „Logs kommen nicht an“, ist das selten nur ein Komfortproblem – es bedeutet meist: Sie verlieren Sichtbarkeit genau dann, wenn Sie sie am dringendsten brauchen. Besonders tückisch ist, dass Syslog in vielen Umgebungen „einfach läuft“, bis eine kleine Änderung alles bricht: ein IP-Wechsel des Logservers, eine neue Firewall-Regel, ein VRF-/Routing-Change, ein Zertifikat bei TLS-Syslog, ein DNS-Problem, eine zu strenge Filterregel oder schlicht ein überlasteter Receiver. Auch die Natur von Syslog ist ein Stolperstein: Häufig wird UDP genutzt, was schnell und simpel ist, aber keine Zustellung garantiert. Bei hohen Lograten oder Paketverlusten entstehen Lücken, ohne dass sofort ein „Fehler“ sichtbar wird. Genau deshalb lohnt sich ein strukturierter Ablauf: Sie prüfen zuerst den Transport (Netzpfad, Port, Protokoll), dann die Konfiguration auf Sender und Receiver, anschließend Parsing/Format und schließlich Kapazität, Rate-Limits und Buffering. Dieser Leitfaden liefert eine praxiserprobte Checkliste, mit der Sie in Minuten eingrenzen, ob das Problem am Gerät, im Netzwerk oder am Log-Backend liegt – und wie Sie es nachhaltig beheben, statt nur „neu zu starten“.

Syslog-Grundlagen: Was beim Logging technisch passiert

Syslog ist kein einzelnes Produkt, sondern ein Log-Transport- und Format-Ökosystem. Vereinfacht gibt es drei Bausteine:

• Sender: Gerät oder System, das Logs erzeugt (Switch, Firewall, Server, Application, WAF, VPN-Gateway).
• Transport: UDP oder TCP, optional verschlüsselt via TLS (oft „syslog over TLS“).
• Receiver/Collector: Syslog-Server, SIEM oder Log-Stack (z. B. rsyslog/syslog-ng, Splunk, Elastic, Graylog), der Logs annimmt, speichert und weiterverarbeitet.

Wichtig: „Logs kommen nicht an“ kann bedeuten, dass sie nie gesendet werden, unterwegs verloren gehen, am Receiver verworfen werden oder zwar ankommen, aber wegen Parsing/Filter nicht sichtbar sind. Genau diese vier Möglichkeiten deckt die Checkliste ab.

Syslog-Ports und Protokolle: UDP, TCP und TLS richtig einordnen

In der Praxis trifft man häufig diese Varianten:

• UDP Syslog: sehr verbreitet, schnell, aber ohne Zustellgarantie. Klassischer Port ist 514/UDP.
• TCP Syslog: zuverlässiger (Connection-orientiert), kann Backpressure auslösen, wenn der Receiver langsam ist.
• Syslog über TLS: verschlüsselt und authentifiziert; häufig Port 6514/TCP, je nach System auch andere Ports.

Warum das wichtig ist: Bei UDP kann „nichts ankommen“ schlicht Packet Loss sein. Bei TCP/TLS kann „nichts ankommen“ ein Handshake-/Zertifikats- oder State-Problem sein. Für Syslog-Protokollgrundlagen ist RFC 5424 (Syslog Message Format) relevant; für Syslog über TLS bietet RFC 5425 den Rahmen.

Typische Symptome: Welche Art Syslog-Problem liegt vor?

Bevor Sie prüfen, kategorisieren Sie das Problem. Das spart Zeit und verhindert, dass Sie am falschen Ende drehen.

• Keine Logs von einem einzelnen Gerät: Sender-Konfiguration, ACL, falsches Interface, DNS, lokale Rate-Limits.
• Keine Logs von einer ganzen Site/VLAN/VRF: Routing/Firewall, NAT, zentrale Policy, VRF-Isolation.
• Logs kommen an, aber „zu spät“ oder lückenhaft: UDP Loss, Receiver überlastet, Queueing, Disk/Indexing, Backpressure bei TCP.
• Nur bestimmte Logtypen fehlen: Facility/Severity-Filter, Rulebase/Policy, Parser/Extractor verwirft Zeilen.
• Nur TLS-Syslog betroffen: Zertifikatskette, Hostname/SNI, TLS-Version, Trust Store, Zeit/NTP.

Die Checkliste: Syslog Troubleshooting Schritt für Schritt

Diese Checkliste ist bewusst „von außen nach innen“ aufgebaut: erst Transport, dann Konfiguration, dann Inhalt/Parsing, dann Kapazität. So finden Sie die Ursache schneller und reproduzierbar.

Schritt: Sender sendet überhaupt?

• Ist Syslog auf dem Gerät aktiviert (global und pro Facility/Severity)?
• Ist das richtige Ziel konfiguriert (IP/Hostname, Port, Protokoll UDP/TCP/TLS)?
• Ist die Quelladresse korrekt (Management-IP vs. Daten-IP)?
• Gibt es lokale Filter, die „nichts“ übriglassen (Severity zu hoch, Facility nicht inkludiert)?

Praxis-Tipp: Viele Geräte senden standardmäßig nur ab einer bestimmten Severity (z. B. warnings). Wenn Sie nur „info“-Logs erwarten, aber nur „errors“ konfigurieren, wirkt es wie ein Transportproblem.

Schritt: Netzwerkpfad prüfen (Ping reicht nicht)

• Kann der Sender den Receiver erreichen (Routing/VRF korrekt)?
• Ist der Syslog-Port erreichbar (UDP/514 oder TCP/514/6514 etc.)?
• Gibt es Firewalls/ACLs zwischen Sender und Receiver, die UDP/TCP blocken?
• Gibt es NAT, das Source-IP verändert und Receiver-Regeln triggert?

Wichtig: ICMP/Ping sagt wenig aus. UDP kann geblockt sein, während Ping durchgeht. Bei TCP können SYNs geblockt werden, obwohl ICMP erlaubt ist.

Schritt: Receiver lauscht wirklich?

• Lauscht der Syslog-Server auf dem erwarteten Port und Protokoll?
• Lauscht er auf der richtigen IP (alle Interfaces vs. nur localhost/Management)?
• Ist die Firewall auf dem Receiver offen (Host-Firewall, Security Groups, Windows Firewall)?
• Ist der Service gestartet und stabil (rsyslog, syslog-ng, Agent/Forwarder)?

Ein Klassiker ist ein Receiver, der nur auf TCP lauscht, während Geräte UDP senden – oder umgekehrt.

Schritt: TLS-spezifische Checks (wenn Syslog über TLS genutzt wird)

• Ist das Zertifikat am Receiver gültig (Ablaufdatum, SAN/Hostname)?
• Vertraut der Sender der ausstellenden CA (Trust Store vorhanden)?
• Stimmen TLS-Versionen und Cipher Suites (Client/Server kompatibel)?
• Ist die Uhrzeit korrekt (NTP), damit Zertifikatsvalidierung nicht fehlschlägt?

Bei TLS sind Zeitprobleme besonders häufig. Wenn NTP driftet, wirken Zertifikate „abgelaufen“ oder „noch nicht gültig“. Als Hintergrund zu TLS ist RFC 8446 (TLS 1.3) hilfreich.

Schritt: Format und Parsing prüfen (Logs kommen an, sind aber „unsichtbar“)

• Kommt am Receiver überhaupt Text an (Rohdaten sichtbar in Input/Raw-Log)?
• Wird das Format korrekt erkannt (RFC3164 vs. RFC5424, Vendor-spezifische Formate)?
• Verwirft der Parser Nachrichten wegen unerwarteter Felder oder Encoding?
• Ist die Zeitzone/Time Parsing korrekt (Events erscheinen „falsch datiert“ und fallen aus dem Dashboard-Fenster)?

Viele SIEMs „verstecken“ Events, wenn Timestamp-Parsing fehlschlägt und die Zeit in die Zukunft oder weit in die Vergangenheit springt. Das sieht aus wie „kommt nicht an“, ist aber ein Parsing-/Timestamp-Thema.

Schritt: Facility/Severity und Filterregeln prüfen

• Welche Facility sendet das Gerät (local0-local7, auth, daemon, kern etc.)?
• Welche Severity sendet es (debug, info, notice, warning, err, crit, alert, emerg)?
• Werden am Receiver nur bestimmte Facilities/Severities angenommen?
• Gibt es Rules, die bestimmte Logtypen droppen (z. B. „noise reduction“)?

Gerade bei Firewalls ist es üblich, nur bestimmte Kategorien zu senden (z. B. deny/critical). Wenn Sie später „allowed“-Logs erwarten, fehlen sie scheinbar.

Schritt: Kapazität, Rate-Limits und Backpressure

• Kommt der Receiver mit der Lograte klar (CPU, Disk I/O, Indexing)?
• Gibt es Queue Drops auf dem Receiver (Input Queue voll)?
• Bei TCP: entstehen Retransmissions/Backpressure, weil der Receiver langsam ist?
• Am Sender: gibt es Rate-Limits, die Logs drosseln oder droppen?

UDP ist besonders anfällig: Bei hoher Loglast gehen Pakete verloren, ohne dass es eine Rückmeldung gibt. Bei TCP kann der Sender blockieren – dann entstehen Verzögerungen und Burst-Verhalten.

Die häufigsten Root Causes in der Praxis

Wenn Sie nur wenig Zeit haben, lohnt es sich, diese „Top 10“ gedanklich durchzugehen. Sie decken die meisten Fälle ab.

• Falscher Port/Protokoll: Sender UDP/514, Receiver TCP/6514 (oder umgekehrt).
• Firewall blockt UDP/514: besonders zwischen Management-VRFs und SIEM-Netzen.
• Falsche Ziel-IP: Logserver umgezogen, DNS zeigt noch auf alte IP.
• ACL auf dem Gerät: nur bestimmte Source-IPs erlaubt, Monitoring-/Logserver-IP geändert.
• Severity zu restriktiv: Gerät sendet nur „errors“, erwartet werden „info“.
• Receiver-Service down: rsyslog/syslog-ng gestoppt oder Listener nicht gebunden.
• Parsing bricht: Vendor-Format nicht unterstützt, Timestamp falsch, Events werden verworfen.
• Überlastung: SIEM/Indexer dropt oder verzögert; UDP Loss oder TCP Backpressure.
• TLS-Zertifikat abgelaufen: Syslog over TLS bricht schlagartig für viele Geräte.
• NTP drift: TLS-Validierung und Log-Timestamps werden unbrauchbar.

Praktische Tests: Wie Sie schnell beweisen, wo es klemmt

Ein gutes Troubleshooting liefert Beweise statt Vermutungen. Mit diesen Tests können Sie den Fehlerpunkt präzise lokalisieren.

• Senderseitig: Testlog erzeugen (z. B. „logger“-Äquivalent) und prüfen, ob er im lokalen Buffer auftaucht.
• Netzwerk: Port-Erreichbarkeit prüfen (UDP ist schwieriger, TCP ist eindeutig durch Connect-Test).
• Receiverseitig: Rohinput beobachten (Raw Input/Listener Debug), ob überhaupt Pakete eintreffen.
• Packet Capture: kurzer Mitschnitt am Receiver-Interface: sehen Sie UDP/514-Pakete? Bei TLS sehen Sie TCP-Verbindungen?
• Parsing: Raw Event vs. parsed Event vergleichen, um Parser-Drops zu entlarven.

Für Paketmitschnitte ist die Wireshark Dokumentation hilfreich, insbesondere um zu prüfen, ob Pakete den Receiver erreichen oder unterwegs verloren gehen.

UDP vs. TCP vs. TLS: Welche Transportwahl stabilisiert Syslog?

Viele Umgebungen nutzen UDP, weil es simpel ist. Das ist okay für „best effort“-Logs, aber riskant bei Compliance- oder Security-Logs. TCP oder TLS erhöht Zuverlässigkeit und Integrität, erfordert aber saubere Kapazitätsplanung.

• UDP: leichtgewichtig, aber Drops bei Last und keine Zustellgarantie.
• TCP: zuverlässiger, aber kann Sender blockieren, wenn Receiver langsam ist (Backpressure).
• TLS: schützt Inhalte und Identität, aber erhöht Overhead und erfordert Zertifikatsmanagement.

Praxisempfehlung: Kritische Security-Logs (Firewalls, VPN, Auth) bevorzugt über TCP/TLS; weniger kritische Telemetrie ggf. über UDP – aber mit Rate-Limits und Monitoring auf Drops.

Best Practices: Syslog so designen, dass Logs auch wirklich ankommen

• Redundanz: Mindestens zwei Log-Receiver (Primary/Secondary) und klare Failover-Strategie.
• Dediziertes Log-Netz: Management/Logging in eigenem VLAN/VRF mit klaren Firewall-Regeln.
• Transport bewusst wählen: UDP nur dort, wo Drops tolerierbar sind; TCP/TLS für kritische Logs.
• Rate-Limits: Senderseitig drosseln, um Burst-Stürme zu vermeiden; Receiver-seitig Queues dimensionieren.
• Parser-Tests: Bei Firmware-Updates oder neuen Gerätemodellen Parsing vorab validieren.
• Zeit/NTP: Konsistente Zeit auf Sendern und Receivern, damit Korrelation und TLS stimmen.
• Self-Monitoring: Alert, wenn ein Sender längere Zeit keine Logs liefert oder wenn Input Drops steigen.

Outbound-Links zur Vertiefung

• RFC 5424: Syslog Message Format (Header, Facility, Severity, Struktur)
• RFC 5425: Syslog over TLS (verschlüsselter Transport)
• RFC 3164: Classic Syslog (Legacy-Format, häufig in Geräten)
• Wireshark Dokumentation: Pakete auf UDP/514 und TCP/6514 sichtbar machen
• rsyslog Dokumentation: Listener, Queues, Rulesets und Fehlersuche

Checkliste: Syslog Troubleshooting – Logs kommen nicht an

• Scope klären: betrifft es ein Gerät, eine Site oder alle Sender? Polling/Traps-Äquivalent gibt es hier nicht – Syslog ist Push.
• Sender prüfen: Syslog aktiviert, Ziel-IP/Hostname korrekt, Port/Protokoll (UDP/TCP/TLS) korrekt, Severity/Facility nicht zu restriktiv.
• Netzpfad prüfen: Routing/VRF korrekt, Firewall/ACL erlaubt UDP/514 bzw. TCP/6514; NAT/Source-IP berücksichtigt.
• Receiver prüfen: Service läuft, lauscht auf richtigem Interface/Port/Protokoll, Host-Firewall offen.
• TLS prüfen (falls genutzt): Zertifikat gültig, CA-Trust korrekt, TLS-Version/Ciphers kompatibel, Zeit/NTP stimmt.
• Parsing prüfen: Raw Logs kommen an, aber Parser/Extractor verwirft? Timestamp/Timezone korrekt? Vendor-Format unterstützt?
• Filter prüfen: Facility/Severity-Filter oder Rules droppen bestimmte Events; „noise reduction“ nicht zu aggressiv.
• Kapazität prüfen: Input Queues, Drops, Disk/Indexing, CPU; bei UDP Packet Loss möglich, bei TCP Backpressure.
• Beweise sammeln: kurzer Packet Capture am Receiver, Zeitfenster notieren, Raw vs. parsed vergleichen.
• Nach Fix verifizieren: Testlog senden, Ankunft im Raw-Input prüfen, dann Sichtbarkeit im Dashboard/SIEM bestätigen und Monitoring/Alerts für Log-Lücken einrichten.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.