Worum geht’s
Viele Tickets im First-Level sind keine Hardware-Defekte, sondern Software- und OS-Probleme: ein hängender Dienst, ein voller Datenträger, ein gesperrtes Konto, eine verräterische Fehlerzeile im Log. Wer Benutzer, Rechte, Prozesse, Dienste und Logs auf Windows und Linux lesen kann, löst diese Fälle oft in Minuten.
Konzept
Benutzer & Rechte. Unter Linux gelten Unix-Permissions (rwx für
Eigentümer/Gruppe/Andere), oft oktal notiert: rwxr-x--- = 750. Windows nutzt
NTFS-ACLs mit benannten Rechten (Lesen, Ändern, Vollzugriff). Grundprinzip beidseits:
Least Privilege — nur so viel Recht wie nötig.
Prozesse & Dienste. Ein Programm läuft als Prozess; im Hintergrund laufen Dienste/Daemons. Werkzeuge:
- Windows: Task-Manager (Prozesse),
services.msc(Dienste), Ereignisanzeige (Logs). - Linux:
top/htop(Prozesse),systemctl(Dienste),journalctl(Logs).
Ein hängender Dienst lässt sich oft per Neustart des Dienstes beheben, ohne den ganzen Rechner neu zu starten.
Logs lesen. Logzeilen tragen meist Zeitstempel, Severity (DEBUG/INFO/WARN/ERROR)
und eine Meldung. Die Kunst: aus vielen Zeilen die relevante Fehlerzeile finden — oft
das erste ERROR oder die Zeile direkt vor dem Ausfall. Probiere Filter und Suche aus:
Datenträger. Ein voller Datenträger ist eine extrem häufige, leicht übersehene
Ursache: Dienste starten nicht, Updates schlagen fehl, Programme stürzen ab. Immer den
freien Speicherplatz prüfen (df -h / Explorer-Eigenschaften).
Beispiel-Fall
Symptom: Eine Webanwendung auf einem Server liefert seit kurzem Fehler. Im Log steht:
08:01:20Z INFO GET /api/users 200 12ms
08:02:03Z ERROR connection to postgres refused (host=db:5432)
08:02:04Z ERROR request failed: GET /api/users 500- Letzte „gute” Zeile:
200um 08:01 — bis dahin lief alles. - Erste Fehlerzeile:
connection to postgres refused— die Datenbank ist nicht erreichbar. - Folgefehler:
500ist nur die Auswirkung, nicht die Ursache. - Root-Cause-Kandidat: Datenbank-Dienst auf
db:5432ist down oder blockiert. - Maßnahme: Status des Postgres-Dienstes prüfen (
systemctl status), ggf. neu starten; Doku ins Ticket.
Die erste ERROR-Zeile zeigt die Ursache — Folgefehler nicht damit verwechseln.
Anwenden
Der Log-Viewer erkennt das Format automatisch und hebt Severities hervor — ideal, um die erste Fehlerzeile zu finden.
- Füge einen Logausschnitt mit gemischten Severities ein.
- Filtere auf ERROR — wo taucht der erste Fehler auf?
- Suche nach 'refused' oder 'failed', um die Ursache von Folgefehlern zu trennen.
Selbsttest
Praxis-Challenge
Du bekommst einen Logausschnitt mit mehreren WARN- und ERROR-Zeilen über zehn
Minuten. Finde im Log-Viewer (1) die letzte fehlerfreie Aktion, (2) die erste
ERROR-Zeile und (3) trenne Ursache von Folgefehler. Schreibe in einem Satz, welcher
Dienst oder welche Ressource die wahrscheinliche Wurzel ist.