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:

Verlassen:

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.