9. Logs, Monitoring und Fehlersuche 9.1 Logs, Monitoring und Fehlersuche Logs und Monitoring sind zentrale Werkzeuge, um Linux-Systeme zu überwachen, Fehler zu finden und Sicherheitsereignisse nachzuvollziehen. Unter Linux werden viele Ereignisse protokolliert: - Systemstarts - Dienststarts - Fehler - Warnungen - Anmeldungen - SSH-Zugriffe - Kernelmeldungen - Paketinstallationen - Netzwerkprobleme - Sicherheitsereignisse Für Fachinformatiker Systemintegration ist dieses Thema besonders wichtig, weil man im Serverbetrieb nicht nur Befehle ausführt, sondern Probleme gezielt anhand von Logs, Messwerten und Statusinformationen eingrenzen muss. Merksatz: Gute Fehlersuche basiert auf Logs, Messwerten und systematischer Eingrenzung. Lernziele Nach dieser Seite solltest du erklären können: - was Logs sind - wo Linux-Logs häufig liegen - was journalctl macht - was /var/log enthält - wie man Dienstlogs prüft - wie man aktuelle Logeinträge live mitliest - wie man CPU, RAM, Speicher und Prozesse prüft - wie man typische Fehlerbilder systematisch eingrenzt - warum Monitoring wichtig ist - was Alerting bedeutet Grundidee Logs sind Protokolle von Ereignissen. Sie helfen bei Fragen wie: - Warum startet ein Dienst nicht? - Warum schlägt eine Anmeldung fehl? - Warum ist ein Server langsam? - Warum ist Speicher voll? - Warum wird eine Verbindung blockiert? - Wann trat der Fehler erstmals auf? - Welcher Benutzer war beteiligt? - Welche Meldung schreibt der Dienst? Merksatz: Logs beantworten oft: was, wann, wo und warum etwas passiert ist. Typische Logquellen Quelle Bedeutung systemd-Journal zentrale systemd-Logs /var/log klassische Logdateien Dienstlogs Logs einzelner Anwendungen Kernelmeldungen Hardware, Treiber, Kernel Authentifizierungslogs Login, sudo, SSH Paketmanager-Logs Installationen und Updates Webserver-Logs HTTP-Zugriffe und Fehler Firewall-Logs erlaubter oder blockierter Verkehr Anwendungslogs Fehler und Ereignisse von Anwendungen Merksatz: Nicht alle Logs liegen an derselben Stelle. /var/log Viele klassische Logdateien liegen unter: /var/log Beispiele: Pfad Bedeutung /var/log/syslog allgemeine Systemmeldungen, häufig Debian/Ubuntu /var/log/messages allgemeine Systemmeldungen, häufig RHEL/Fedora-Umfeld /var/log/auth.log Authentifizierung, häufig Debian/Ubuntu /var/log/secure Authentifizierung, häufig RHEL/Fedora-Umfeld /var/log/kern.log Kernelmeldungen, je nach Distribution /var/log/dmesg Boot- und Kernelmeldungen, je nach Distribution /var/log/nginx Nginx-Logs /var/log/apache2 Apache-Logs /var/log/apt apt-Logs /var/log/journal dauerhaftes systemd-Journal, falls aktiviert Wichtig: Welche Dateien vorhanden sind, hängt von Distribution, Diensten und Logging-Konfiguration ab. Merksatz: /var/log ist der klassische Ort für Logdateien. systemd-Journal Auf vielen modernen Linux-Systemen sammelt systemd Logs im Journal. Das Journal enthält unter anderem: - Systemmeldungen - Dienstmeldungen - Bootmeldungen - Fehler - Warnungen - Logs einzelner Units Auswertung mit: journalctl Merksatz: journalctl liest das systemd-Journal. journalctl Grundlagen Alle Journal-Einträge anzeigen: journalctl Letzte Einträge anzeigen: journalctl -n 50 Live mitlesen: journalctl -f Logs seit letztem Boot: journalctl -b Logs eines Dienstes: journalctl -u ssh Live-Logs eines Dienstes: journalctl -u ssh -f Merksatz: journalctl ist eines der wichtigsten Werkzeuge für Linux-Fehlersuche. Dienstlogs mit journalctl Wenn ein Dienst Probleme macht, prüft man zuerst: systemctl status dienstname Dann: journalctl -u dienstname Beispiel: systemctl status nginx journalctl -u nginx Nur letzte Einträge: journalctl -u nginx -n 50 Live mitlesen: journalctl -u nginx -f Seit letztem Boot: journalctl -u nginx -b Merksatz: Dienstproblem: status prüfen, dann journalctl -u. Zeitfilter bei journalctl journalctl kann nach Zeit filtern. Beispiele: journalctl --since "1 hour ago" journalctl --since "today" journalctl --since "2026-07-08 10:00" journalctl --until "2026-07-08 12:00" Kombiniert mit Dienst: journalctl -u ssh --since "today" Merksatz: Zeitfilter helfen, Fehler auf einen Zeitraum einzugrenzen. Prioritäten bei journalctl Logs haben Prioritäten. Nur Fehler anzeigen: journalctl -p err Warnungen und Schlimmeres anzeigen: journalctl -p warning Häufige Prioritäten: Priorität Bedeutung emerg System unbenutzbar alert sofortiges Eingreifen nötig crit kritischer Fehler err Fehler warning Warnung notice Hinweis info Information debug Debug-Ausgabe Merksatz: journalctl -p err zeigt Fehler. dmesg dmesg zeigt Kernelmeldungen. Befehl: dmesg Menschenlesbare Zeitstempel: dmesg -T Typische Inhalte: - Hardwareerkennung - Treiberprobleme - USB-Geräte - Festplattenfehler - Kernelwarnungen - Netzwerkadapter - Dateisystemfehler Merksatz: dmesg hilft bei Kernel-, Hardware- und Treiberproblemen. Logdateien mit less lesen Lange Logdateien liest man besser mit less. Beispiel: less /var/log/syslog In less suchen: /error Nächster Treffer: n Verlassen: q Merksatz: less ist besser als cat für lange Logs. Logdateien live mitlesen Mit tail kann man neue Logeinträge live verfolgen. Beispiel: tail -f /var/log/syslog Letzte 100 Zeilen und live weiter: tail -n 100 -f /var/log/syslog Typische Nutzung: Dienst neu starten gleichzeitig Logs beobachten Fehler direkt sehen Merksatz: tail -f liest neue Logeinträge live mit. grep in Logs Mit grep sucht man gezielt nach Begriffen. Beispiele: grep -i "error" /var/log/syslog grep -i "failed" /var/log/auth.log grep -i "denied" /var/log/auth.log Mit Zeilennummer: grep -n "error" datei.log Groß-/Kleinschreibung ignorieren: grep -i "error" datei.log Merksatz: grep filtert relevante Logzeilen. Typische Suchbegriffe in Logs Suchbegriff Mögliche Bedeutung error Fehler failed fehlgeschlagen denied verweigert refused abgelehnt timeout Zeitüberschreitung not found nicht gefunden permission Rechteproblem authentication Anmeldung invalid ungültig disconnect Verbindung getrennt no space Speicherproblem read-only nur lesbares Dateisystem Merksatz: Gute Suchbegriffe beschleunigen Logauswertung. Logrotation Logs wachsen mit der Zeit. Damit sie nicht unbegrenzt Speicher verbrauchen, werden sie rotiert. Logrotation bedeutet: alte Logs werden umbenannt, komprimiert, gelöscht oder archiviert. Typisches Werkzeug: logrotate Beispielhafte rotierte Dateien: syslog syslog.1 syslog.2.gz Merksatz: Logrotation verhindert, dass Logs den Speicher füllen. Warum Logs Speicher füllen können Logs können sehr groß werden, wenn: ein Dienst ständig Fehler schreibt Debug-Logging aktiviert ist Angriffe viele Einträge erzeugen Logrotation nicht funktioniert ein Dienst in einer Fehlerschleife hängt Folgen: Dateisystem voll Dienste können nicht schreiben Updates schlagen fehl System wird instabil Prüfen: df -h du -sh /var/log Merksatz: Viele Logs können Ursache und Folge eines Problems sein. Monitoring Monitoring bedeutet: Systeme, Dienste Ressourcen und Zustände regelmäßig überwachen. Überwacht werden zum Beispiel: - CPU - RAM - Speicherplatz - Inodes - Netzwerk - Dienste - Ports - Antwortzeiten - Backups - Zertifikate - Logs - Sicherheitsereignisse Merksatz: Monitoring soll Probleme erkennen, bevor Benutzer sie melden. Alerting Alerting bedeutet: Bei bestimmten Ereignissen oder Grenzwerten wird eine Benachrichtigung ausgelöst. Beispiele: Speicher über 90 Prozent Backup fehlgeschlagen Dienst nicht erreichbar Zertifikat läuft bald ab CPU dauerhaft sehr hoch viele fehlgeschlagene Logins Wichtig: Alarme müssen sinnvoll sein. Zu viele unwichtige Alarme führen zu Alarmmüdigkeit. Merksatz: Alerting macht aus Monitoring eine aktive Warnung. Wichtige Systemwerte Wert Warum wichtig? CPU hohe Last kann Dienste verlangsamen RAM Speichermangel führt zu Swap oder Fehlern Swap starke Nutzung kann System verlangsamen Speicherplatz volle Dateisysteme verhindern Schreibzugriffe Inodes zu viele Dateien verhindern neue Dateien Load Average zeigt Systemlast Netzwerk Verbindungsprobleme oder Paketverlust Dienststatus zeigt, ob Dienste laufen Logs zeigen Ursachen und Fehler Merksatz: Langsame Systeme brauchen Messwerte, keine Vermutungen. CPU und Prozesse prüfen Prozesse und CPU prüfen mit: top oder: htop Prozesse anzeigen: ps aux Nach Prozess suchen: ps aux | grep nginx Mögliche Ursachen hoher CPU: hohe Nutzerlast Endlosschleife fehlerhafter Prozess Angriff falsche Konfiguration Merksatz: Hohe CPU immer pro Prozess einordnen. RAM und Swap prüfen RAM prüfen: free -h Live prüfen: top Swap prüfen: swapon --show Mögliche Fehlerbilder: System langsam Prozesse werden beendet starke Swap-Nutzung Dienst startet nicht Out-of-Memory-Ereignis Merksatz: Swap ist langsamer als RAM. Viel Swap kann System stark verlangsamen. Out of Memory Wenn der Arbeitsspeicher knapp wird, kann Linux Prozesse beenden, um das System zu stabilisieren. Das nennt man häufig: OOM oder: Out of Memory Suchen in Logs: journalctl -k | grep -i "out of memory" dmesg -T | grep -i "killed process" Merksatz: Wenn Prozesse plötzlich verschwinden, OOM in Kernelmeldungen prüfen. Speicherplatz prüfen Dateisysteme prüfen: df -h Inodes prüfen: df -i Große Ordner prüfen: du -sh /var/log du -sh /var/lib du -sh /home/* Typische Ursachen: Logs Backups Datenbanken Container-Images Cache temporäre Dateien Merksatz: No space left on device: df -h und df -i prüfen. Netzwerk prüfen IP-Adressen: ip addr Routen: ip route Gateway testen: ping -c 4 gateway-ip DNS prüfen: dig example.com Ports prüfen: ss -tulpen Webdienst prüfen: curl -I http://localhost Merksatz: Netzwerkfehler Schritt für Schritt prüfen: IP, Route, DNS, Port, Dienst. Dienststatus prüfen Dienststatus: systemctl status dienstname Autostart prüfen: systemctl is-enabled dienstname Aktiv prüfen: systemctl is-active dienstname Logs prüfen: journalctl -u dienstname Merksatz: Dienstfehler: systemctl status und journalctl -u. HTTP-Fehler einordnen Code Bedeutung Wahrscheinliche Richtung 200 OK Dienst antwortet 301 / 302 Weiterleitung Webserver oder Anwendung 401 nicht authentifiziert Login fehlt oder falsch 403 verboten Rechteproblem 404 nicht gefunden Pfad oder Ressource falsch 500 interner Serverfehler Anwendung oder Backend 502 Bad Gateway Proxy erreicht Backend nicht 503 Dienst nicht verfügbar Backend oder Dienst nicht bereit Merksatz: HTTP-Code zeigt, auf welcher Ebene man weiter suchen sollte. Fehlersuche nach Änderung Wenn ein Fehler direkt nach einer Änderung auftritt, ist diese Änderung besonders relevant. Mögliche Änderungen: Update Konfigurationsänderung Firewall-Regel Rechteänderung Zertifikatswechsel Mountänderung DNS-Änderung Neustart Sinnvolle Fragen: Was wurde geändert? Wann wurde geändert? Wer hat geändert? Gibt es ein Backup? Gibt es einen Rollback-Plan? Merksatz: Fehler nach Änderung: Änderung zuerst prüfen. Systematische Fehlersuche Eine gute Reihenfolge: 1. Fehler genau beschreiben 2. Zeitpunkt feststellen 3. betroffene Systeme eingrenzen 4. letzte Änderungen prüfen 5. Status prüfen 6. Logs prüfen 7. Ressourcen prüfen 8. Netzwerk prüfen 9. Berechtigungen prüfen 10. Maßnahme testen und dokumentieren Merksatz: Nicht raten, sondern eingrenzen. Einzelnes System oder viele Systeme? Wichtige Eingrenzung: Betroffen Wahrscheinliche Richtung ein Benutzer Benutzerrechte, Client, Konto alle Benutzer Dienst, Server, Netzwerk, Authentifizierung ein Server Dienst, Ressourcen, lokale Konfiguration alle Server Netzwerk, DNS, zentrale Dienste eine Anwendung Anwendung, Datenbank, Backend mehrere Anwendungen Infrastruktur, DNS, Storage, Netzwerk Merksatz: Anzahl der Betroffenen hilft bei der Eingrenzung. Typische Linux-Fehlerbilder Fehlerbild Wahrscheinliche Ursache Dienst startet nicht Konfiguration, Rechte, Port, Abhängigkeit Permission denied Rechteproblem No such file or directory falscher Pfad oder Datei fehlt No space left on device Speicherplatz oder Inodes voll Read-only file system Dateisystem nur lesbar oder Fehler Connection refused Dienst läuft nicht oder Port geschlossen Connection timed out Firewall, Routing oder Ziel nicht erreichbar Name or service not known DNS oder Name falsch Too many open files Limit für offene Dateien erreicht Out of memory RAM knapp, OOM-Killer aktiv Target is busy Mount oder Datei wird noch verwendet Connection refused Bedeutung: Das Zielsystem ist erreichbar, aber der Dienst nimmt auf diesem Port keine Verbindung an. Mögliche Ursachen: Dienst läuft nicht falscher Port Dienst lauscht nur auf anderer Adresse lokale Firewall lehnt aktiv ab Prüfen: systemctl status dienst ss -tulpen journalctl -u dienst Merksatz: Connection refused: Ziel erreichbar, Dienst oder Port problematisch. Connection timed out Bedeutung: Die Verbindung erhält keine Antwort innerhalb der Zeit. Mögliche Ursachen: Firewall verwirft Pakete Routingproblem Ziel nicht erreichbar falsche IP Netzwerkproblem Cloud Security Group blockiert Prüfen: ping ip route Firewall-Regeln Netzwerkpfad Merksatz: Timeout deutet oft auf Firewall, Routing oder Nichterreichbarkeit hin. Permission denied Bedeutung: Zugriff verweigert. Mögliche Ursachen: fehlende Dateirechte falscher Besitzer falsche Gruppe fehlendes x-Recht auf Verzeichnis sudo nötig Dienstbenutzer hat keine Rechte Prüfen: whoami id ls -l datei ls -ld verzeichnis Merksatz: Permission denied ist meist ein Rechteproblem. No such file or directory Bedeutung: Datei oder Verzeichnis existiert nicht. Mögliche Ursachen: falscher Pfad Tippfehler falsche Groß-/Kleinschreibung Datei wurde gelöscht Mount fehlt relativer Pfad falsch verstanden Prüfen: pwd ls -la find mount Merksatz: Linux unterscheidet Groß- und Kleinschreibung. Too many open files Bedeutung: Ein Prozess oder Benutzer hat zu viele Dateien, Sockets oder Verbindungen geöffnet. Mögliche Ursachen: hohe Last Fehler in Anwendung zu niedriges Limit Verbindungsleck Prüfen: Logs Prozessstatus Limits offene Dateien Merksatz: Unter Linux zählen auch Netzwerkverbindungen als offene Dateien. Logs und Sicherheit Logs sind auch für Sicherheit wichtig. Wichtige Ereignisse: fehlgeschlagene Logins sudo-Nutzung SSH-Zugriffe neue Benutzer Rechteänderungen Dienststarts Firewall-Blockierungen ungewöhnliche Prozesse viele Anmeldeversuche Beispiele: journalctl -u ssh grep -i "failed" /var/log/auth.log grep -i "sudo" /var/log/auth.log Merksatz: Sicherheitsanalyse beginnt oft in Auth- und Dienstlogs. Backup und Logs Logs können nach einem Vorfall wichtig sein. Aber: Logs auf demselben kompromittierten System können manipuliert werden. Besser: zentrale Logsammlung SIEM manipulationsgeschützte Logs Zeitserver verwenden ausreichende Aufbewahrung Merksatz: Für Sicherheitsvorfälle sind zentrale und geschützte Logs wertvoll. Zeit und Logs Korrekte Uhrzeit ist für Logs wichtig. Wenn die Systemzeit falsch ist, werden Ereignisse schwer nachvollziehbar. Prüfen: timedatectl Zeitdienst prüfen: systemctl status systemd-timesyncd oder je nach System: chrony ntpd Merksatz: Ohne korrekte Zeit sind Logs schwer auswertbar. Dokumentation bei Fehlersuche Bei Fehlersuche dokumentieren: - Fehlerbild - Zeitpunkt - betroffene Systeme - ausgeführte Prüfungen - relevante Logmeldungen - Ursache - Maßnahme - Ergebnis - offene Punkte Warum? Nachvollziehbarkeit Wiederverwendbarkeit Übergabe an Kollegen spätere Analyse Prüfungsrelevanz Merksatz: Gute Administration dokumentiert Fehler und Lösung. Typische Befehle dieser Seite Befehl Zweck journalctl systemd-Journal anzeigen journalctl -u dienst Logs eines Dienstes anzeigen journalctl -f Logs live mitlesen journalctl -b Logs seit letztem Boot dmesg Kernelmeldungen anzeigen dmesg -T Kernelmeldungen mit lesbarer Zeit less logfile lange Logdatei lesen tail -f logfile Log live verfolgen grep muster logfile Log nach Muster filtern systemctl status dienst Dienststatus prüfen top Prozesse und Last live prüfen free -h RAM und Swap prüfen df -h Speicherplatz prüfen df -i Inodes prüfen du -sh ordner Ordnergröße prüfen ip addr IP-Adressen prüfen ip route Routing prüfen ss -tulpen Ports prüfen curl -I URL Webantwort prüfen timedatectl Uhrzeit und Zeitsynchronisation prüfen Typische Prüfungsfragen Frage Kurzantwort Was sind Logs? Protokolle von Ereignissen Wo liegen viele klassische Logs? /var/log Was macht journalctl? systemd-Journal anzeigen Wie zeigt man Dienstlogs? journalctl -u dienst Wie liest man Logs live mit? tail -f oder journalctl -f Was macht dmesg? Kernelmeldungen anzeigen Was ist Monitoring? regelmäßige Überwachung Was ist Alerting? Benachrichtigung bei Ereignissen Warum ist Logrotation wichtig? verhindert zu große Logs Was prüft df -h? Speicherplatz Was prüft free -h? RAM und Swap Was bedeutet Connection refused? Ziel erreichbar, Dienst/Port lehnt ab Was bedeutet Connection timed out? keine Antwort, oft Firewall/Routing Warum ist korrekte Zeit wichtig? Logs müssen zeitlich stimmen Typische Prüfungsfallen Falle Richtig denken Logs ignorieren Logs liefern Ursache und Zeitbezug nur Dienst neu starten erst Status und Logs prüfen cat für riesige Logs nutzen less, tail oder grep verwenden Monitoring mit Logging verwechseln Logs protokollieren, Monitoring überwacht Alerting vergessen Monitoring ohne Alarm wird leicht übersehen hohe CPU ohne Prozessbezug nennen verursachenden Prozess ermitteln Speicher frei, aber Fehler beim Schreiben Inodes prüfen Zeitfehler ignorieren falsche Zeit erschwert Loganalyse Connection refused und timed out gleichsetzen unterschiedliche Ursachen nach Änderung nicht an Rollback denken Änderungen dokumentieren und absichern IHK-sichere Kurzformulierung Logs sind Protokolle von Ereignissen und dienen der Fehlersuche, Überwachung und Sicherheitsanalyse. Viele klassische Logdateien liegen unter /var/log, während auf systemd-Systemen journalctl das zentrale Journal auswertet. Dienstprobleme werden typischerweise mit systemctl status und journalctl -u geprüft. tail -f oder journalctl -f können neue Logeinträge live anzeigen. Monitoring überwacht Ressourcen und Dienste wie CPU, RAM, Speicherplatz, Inodes, Netzwerk, Ports, Backups und Zertifikate. Alerting benachrichtigt bei Grenzwerten oder Fehlern. Eine systematische Fehlersuche grenzt das Problem anhand von Fehlerbild, Zeitpunkt, betroffenen Systemen, Logs, Ressourcen, Netzwerk, Rechten und letzten Änderungen ein. Merksätze Logs zeigen Ereignisse. Monitoring überwacht Zustände. Alerting warnt aktiv. /var/log enthält viele klassische Logs. journalctl liest das systemd-Journal. journalctl -u zeigt Dienstlogs. journalctl -f liest live mit. journalctl -b zeigt Logs seit letztem Boot. dmesg zeigt Kernelmeldungen. less ist gut für lange Logs. tail -f liest Logdateien live mit. grep filtert relevante Logzeilen. Logrotation verhindert zu große Logs. df -h prüft Speicherplatz. df -i prüft Inodes. free -h prüft RAM und Swap. top zeigt Last und Prozesse. ss zeigt Ports. curl prüft HTTP oder HTTPS. systemctl status zeigt Dienstzustand. Connection refused: Dienst oder Port problematisch. Connection timed out: Firewall, Routing oder Nichterreichbarkeit. Permission denied: Rechteproblem. No space left on device: Speicherplatz oder Inodes prüfen. Nach Änderung zuerst Änderung prüfen. Nicht raten, sondern eingrenzen. Gute Fehlersuche wird dokumentiert. Korrekte Uhrzeit ist wichtig für Logs.