# Process Monitoring: Den Puls des Systems fühlen

TL;DR / Management Summary Ein Server ist nur so gut wie seine Antwortzeiten. Wenn das System träge wird, muss ein Senior Admin sofort sehen können, welcher Prozess die Ressourcen frisst. Während der Klassiker top auf jedem System vorhanden ist, bieten moderne Alternativen wie htop und btop eine deutlich intuitivere Übersicht über CPU-Kerne, RAM-Auslastung und I/O-Last. In diesem Modul lernen wir, wie man “Ressourcen-Diebe” identifiziert und sicher beendet.

# 1. Einführung & Architektur

Die Sicht auf den Scheduler.

Der Linux-Kernel verwaltet Prozesse über den Scheduler. Monitoring-Tools lesen diese Daten aus dem virtuellen /proc Dateisystem aus.

# Die Metriken (Mermaid)

graph TD
    A[Linux Kernel: /proc] --> B{Monitoring Tool}
    B --> C[top: The Classic]
    B --> D[htop: Interactive]
    B --> E[btop: Modern / Visual]
    subgraph "KPIs"
        F[Load Average: 1, 5, 15 min]
        G[CPU: User, System, Wait, Steal]
        H[Memory: RAM vs Swap]
        I[Processes: PID, State, Nice]
    end
    C/D/E --- F
    C/D/E --- G
    C/D/E --- H
    C/D/E --- I

# 2. htop: Der Admin-Favorit

Interaktive Kontrolle.

Im Gegensatz zu top erlaubt htop das Scrollen (horizontal/vertikal) und die Bedienung per Maus.

# Wichtige Funktionen

• F2 (Setup): Farben und Spalten anpassen.
• F5 (Tree): Zeigt die Eltern-Kind-Beziehung von Prozessen (z.B. Nginx-Master vs. Worker).
• F6 (Sort): Sortieren nach CPU, RAM oder Zeit.
• F9 (Kill): Sendet Signale (z.B. SIGTERM) an den markierten Prozess.

# 3. btop: Das Dashboard der Zukunft

Maximale Visualisierung.

btop bietet eine grafische Darstellung von Netzwerk-Traffic, Disk-I/O und CPU-Frequenzen direkt im Terminal.

sudo pacman -S btop # Arch
apk add btop # Alpine

# 4. Day-2 Operations: Signale senden

Prozesse bändigen.

Ein Prozess lässt sich nicht stoppen? Nutzen Sie die verschiedenen Eskalationsstufen:

1. SIGTERM (15): Die freundliche Bitte (“Bitte beende dich sauber”).
2. SIGKILL (9): Der gewaltsame Abbruch durch den Kernel (kein Cleanup möglich).
3. SIGHUP (1): Signalisiert dem Prozess, seine Konfiguration neu zu laden.

# 5. Troubleshooting & “War Stories”

Wenn die Last lügt.

# Story 1: “Der Ghost-Load (IO Wait)”

Symptom: Die Load-Average steht bei 10.0, aber die CPU-Auslastung ist bei 2%. Der Server reagiert trotzdem kaum. Ursache: Hohe IO-Wait Werte (%wa). Prozesse warten auf die Festplatte (oder einen hängenden NFS-Mount). Lösung: Nutzen Sie iotop (Artikel 267), um herauszufinden, welcher Prozess die Disk blockiert. Ein hoher Load ohne CPU-Last deutet fast immer auf I/O-Hänger hin.

# Story 2: “CPU Steal Time in der VM”

Symptom: Ein SLES-Server in der Cloud zeigt 100% CPU-Last, obwohl die Applikation nichts tut. htop zeigt einen hohen Wert bei %st. Ursache: CPU Steal Time. Der physikalische Host ist überbucht. Andere VMs klauen Ihrem Server die Rechenzeit. Lösung: Informieren Sie den Cloud-Provider oder verschieben Sie den Workload auf einen weniger ausgelasteten Node.

# 6. Fazit & Empfehlung

• Pflicht: Installieren Sie htop auf jedem System. Es spart wertvolle Sekunden bei der Fehlersuche.
• Visualisierung: Nutzen Sie btop für Monitoring-Monitore im Büro – es zeigt alle relevanten Hardware-Daten auf einen Blick.
• Wahl: Nutzen Sie das klassische top nur dann, wenn Sie auf einem fremden System ohne Internetzugriff arbeiten müssen.

# Anhang: Cheatsheet