System-Monitoring mit top, htop und Alternativen

1. Load Average richtig einordnen: uptime, nproc und die Drei-Werte-Regel

Der Befehl uptime liefert drei Zahlen, die exponentiell gewichtete gleitende Durchschnitte der Länge der Run-Queue über die letzten 1, 5 und 15 Minuten darstellen. Unter Linux zählt die Run-Queue nicht nur Prozesse, die auf die CPU warten, sondern auch Prozesse im Zustand D (uninterruptible sleep), die auf blockierende I/O warten. Das unterscheidet Linux von klassischen BSD-Systemen, bei denen ausschließlich CPU-wartende Prozesse gezählt werden. Eine hohe Load Average bedeutet also nicht zwangsläufig CPU-Engpass, sie kann ebenso gut auf einen überlasteten Storage-Controller oder hängende NFS-Mounts hindeuten.

Um eine Load-Zahl sinnvoll zu bewerten, muss man sie ins Verhältnis zur Anzahl der verfügbaren CPU-Kerne setzen, die nproc liefert. Eine Load von 4.0 auf einem Vier-Kern-Server bedeutet, dass die CPUs im Schnitt voll ausgelastet waren, aber noch keine Prozesse in der Warteschlange standen. Steigt die Load deutlich über die Kernanzahl, warten Prozesse aktiv auf Ressourcen. Der Trend über die drei Zeitfenster ist dabei aussagekräftiger als ein einzelner Momentwert: Steigt die 1-Minuten-Load stark über die 15-Minuten-Load, handelt es sich um eine akute Spitze, kein Dauerzustand.

# prometheus-alerts.yml
# Alert when load average per core stays above 1.0 for a sustained period
groups:
  - name: system-load
    rules:
      - alert: HighLoadPerCore
        expr: node_load5 / count without (cpu, mode) (node_cpu_seconds_total{mode="idle"}) > 1.0
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Load average per core exceeds 1.0 on {{ $labels.instance }}"
          description: "5m load / core count has been above 1.0 for 10 minutes. Check top/htop for the offending process."

2. Die Kopfzeile von top richtig lesen: Tasks, %Cpu(s), Mem, Swap

Die ersten fünf Zeilen von top enthalten mehr belastbare Informationen als die gesamte darunter liegende Prozessliste, werden aber oft ignoriert. Die Tasks-Zeile listet die Gesamtzahl der Prozesse sowie deren Aufteilung in running, sleeping, stopped und zombie. Eine wachsende Zahl an Zombies deutet auf einen Elternprozess hin, der wait() nicht korrekt aufruft. Die %Cpu(s)-Zeile schlüsselt die CPU-Zeit in us (User), sy (System/Kernel), ni (Nice-angepasste Prozesse), id (Idle), wa (I/O-Wait), hi/si (Hardware-/Software-Interrupts) und st (Steal-Time bei virtualisierten Umgebungen) auf.

Ein hoher wa-Wert weist auf einen I/O-Engpass hin, während st ungleich Null auf einer Cloud-VM bedeutet, dass der Hypervisor der eigenen VM CPU-Zeit entzieht, was intern nicht lösbar ist. Die Mem- und Swap-Zeilen zeigen total, free, used und buff/cache. Entscheidend ist nicht free, sondern available in /proc/meminfo, da der Linux-Kernel Speicher für Page-Cache aggressiv nutzt und bei Bedarf sofort wieder freigibt. Ein niedriger free-Wert bei hohem buff/cache ist in aller Regel unproblematisch. Ein Beispiel-Header sieht etwa so aus: load average: 3.84, 2.91, 2.20 mit 7.1 wa, was bereits vor der Prozessliste auf einen I/O-Engpass hindeutet, und 2 zombie, was auf einen Elternprozess ohne korrekten wait()-Aufruf hinweist.

3. top interaktiv bedienen: Sortieren, Filtern und wichtige Tasten

Im interaktiven Modus liefert top eine Reihe von Tastenkürzeln, die den Unterschied zwischen einem schnellen Fund und minutenlangem Scrollen ausmachen. Shift+P sortiert nach CPU-Auslastung, Shift+M nach residentem Speicher, Shift+N nach PID. Mit u filtert man die Ansicht auf einen bestimmten Benutzer, etwa www-data für PHP-FPM-Worker, mit o lässt sich ein beliebiger Filterausdruck wie COMMAND=nginx definieren. Die Taste 1 schaltet zwischen aggregierter CPU-Anzeige und Einzeldarstellung pro Kern um, was bei Multithread-Workloads mit ungleicher Kernauslastung sofort auffällt.

Mit c wird die vollständige Kommandozeile inklusive Argumente angezeigt statt nur des Programmnamens, was bei mehreren PHP-FPM-Pools mit identischem Binary entscheidend ist, um den richtigen Pool zu identifizieren. k sendet ein Signal an eine PID, r passt die Nice-Priorität an, ohne den Prozess zu beenden. Für Automatisierung ist der Batch-Modus mit -b in Kombination mit -n für die Anzahl der Durchläufe wichtig, da er ohne Terminal-Steuerzeichen auskommt und sich in Cron-Jobs und Log-Dateien nutzen lässt.

4. htop im Vergleich zu top: Farbcodierung, Baumansicht, Mauskontrolle

htop stellt dieselben Kerninformationen wie top dar, präsentiert sie aber in einer deutlich zugänglicheren Form. Die farbcodierten Meter-Balken am oberen Rand zeigen CPU-Auslastung pro Kern, Speicher und Swap grafisch an, sodass ein Engpass auf einen Blick erkennbar ist, bevor man überhaupt eine einzelne Zeile liest. Die Taste F5 schaltet in die Baumansicht um und macht Eltern-Kind-Beziehungen sofort sichtbar, was bei verschachtelten Prozessgruppen wie einem PHP-FPM-Master mit vielen Workern deutlich schneller zum Ziel führt als das manuelle Verfolgen von PPID-Spalten in top.

Mit F6 öffnet sich ein Sortiermenü mit allen verfügbaren Spalten, F9 zeigt eine Liste wählbarer Signale statt nur SIGTERM per Default. Mausklicks auf Spaltenköpfe sortieren direkt, ein Klick auf einen Prozess markiert ihn dauerhaft farblich, auch wenn sich seine Position in der sortierten Liste ändert. Die Konfiguration inklusive Spaltenauswahl und Farbschema wird persistent in ~/.config/htop/htoprc gespeichert, sodass jede SSH-Session dieselbe individualisierte Ansicht zeigt. Für schnelle interaktive Diagnose auf einem einzelnen Server ist htop in fast jedem Fall die bessere Wahl, top bleibt aber die zuverlässigere Option in Skripten, weil es auf praktisch jedem Linux-System vorinstalliert ist.

5. Pro-Prozess-Speicher richtig lesen: VIRT, RES, SHR

Die drei Speicherspalten in top und htop werden regelmäßig falsch interpretiert. VIRT (Virtual Memory) umfasst den gesamten virtuellen Adressraum eines Prozesses, inklusive gemappter Bibliotheken, reservierter aber ungenutzter Heap-Bereiche und Memory-Mapped Files. Ein hoher VIRT-Wert allein ist selten ein Problem, da virtueller Adressraum billig ist und erst bei tatsächlichem Zugriff physischen Speicher belegt. RES (Resident Set Size) zeigt den Anteil, der aktuell tatsächlich im physischen RAM liegt, einschließlich gemeinsam genutzter Bibliotheken.

Genau darin liegt die Falle: SHR (Shared Memory) ist der Teil von RES, der mit anderen Prozessen geteilt wird, etwa libc oder gemeinsame Shared-Memory-Segmente einer Datenbank. Addiert man die RES-Werte aller PHP-FPM-Worker eines Pools, zählt man geteilte Bibliotheken mehrfach und überschätzt den tatsächlichen Speicherverbrauch massiv. Für eine korrekte Summe ist die PSS (Proportional Set Size) relevant, die geteilten Speicher anteilig auf alle nutzenden Prozesse verteilt. Werkzeuge wie smem -tk oder ein direkter Blick in /proc/<pid>/smaps_rollup liefern diese präzisere Zahl, die weder top noch htop standardmäßig anzeigen.

6. Sortieren und Filtern: den tatsächlichen Übeltäter identifizieren

Bei einem akuten Lastproblem führt der direkte Weg über Sortierung schneller zum Ziel als das Scrollen durch die komplette Prozessliste. In htop sortiert F6 gefolgt von PERCENT_CPU oder M_RESIDENT sofort nach dem relevanten Kriterium, während in top die Tasten Shift+P und Shift+M denselben Effekt haben. Bei mehreren identischen Diensten, etwa einem MySQL-Server mit vielen Verbindungs-Threads oder einem PHP-FPM-Pool, reicht eine sortierte Ansicht des Hauptprozesses aber oft nicht aus, weil ein einzelner heißer Thread hinter der aggregierten Prozesszeile verborgen bleibt.

Genau hier hilft die Thread-Ansicht: In htop blendet Shift+H alle Threads einzeln ein, in top aktiviert die Taste H denselben Modus. Damit wird sichtbar, welcher einzelne Thread innerhalb eines Multithread-Prozesses wie mysqld tatsächlich 100 Prozent eines Kerns beansprucht, was bei aggregierter Ansicht verborgen bliebe. Kombiniert mit einem Filter auf den verdächtigen Prozessnamen über o beziehungsweise die Suchfunktion / in htop lässt sich der Kreis der Kandidaten in wenigen Sekunden auf eine einzelne PID eingrenzen.

# Find the single hottest thread inside a multithreaded process (e.g. mysqld)
top -H -p "$(pgrep -o mysqld)"

# Cross-check via /proc: per-thread CPU time for a given PID
ps -L -o pid,lwp,pcpu,stat,comm -p 4211 --sort=-pcpu | head -n 5

# htop equivalent workflow (interactive, keys annotated):
#   F6            -> sort menu, choose PERCENT_CPU
#   Shift+H       -> toggle per-thread view
#   /             -> search/filter by process or command name
#   F9            -> send a specific signal (not just SIGTERM) to the found PID

7. Moderne Alternativen: btop und glances im Vergleich

btop ist eine in C++ geschriebene Weiterentwicklung des jüngeren bpytop-Projekts und bringt gegenüber htop vor allem grafische Verlaufsdiagramme für CPU, Speicher, Netzwerk und Disk-I/O mit, die sich über die Zeit aufbauen statt nur den Momentwert zu zeigen. Volle Mausunterstützung erlaubt das Ein- und Ausklappen von Prozessbäumen per Klick, integrierte Themes und, bei vorhandenen Treibern, sogar GPU-Auslastung für Nvidia-Karten machen es zur bevorzugten Wahl für längere interaktive Diagnosesitzungen auf einem einzelnen Host.

glances verfolgt einen anderen Ansatz: Es ist in Python geschrieben, plattformübergreifend nutzbar und bietet neben dem TUI zusätzlich ein Web-Interface sowie eine REST-API. Im Client-Server-Modus (glances -s auf dem Zielserver, glances -c <host> vom Arbeitsplatz aus) lässt sich ein entferntes System überwachen, ohne sich per SSH einzuloggen. Exporte nach InfluxDB, Prometheus oder CSV machen glances zur Brücke zwischen interaktivem Debugging und zentralem Monitoring, während top und htop rein lokal ausgelegt bleiben.

; /etc/glances/glances.conf
; Enable web server mode and export metrics for central monitoring

[global]
refresh = 3
history_size = 1200

[cpu]
disable = False
career_max_history = 200

[outputs]
max_processes_display = 20

[influxdb]
host = influxdb.internal.mironsoft.de
port = 8086
db = glances
prefix = webserver01

8. Wann lohnt sich die Zusatzinstallation von btop oder glances

Für eine schnelle, einmalige SSH-Diagnose auf einem einzelnen Server reichen top und htop in der Regel vollständig aus, zumal beide auf fast jeder Distribution vorinstalliert oder über die Standard-Paketquellen sofort verfügbar sind. Die Zusatzinstallation von btop lohnt sich, sobald man längere Diagnosesitzungen fährt und historische Verläufe braucht, etwa um zu sehen, ob ein CPU-Spike bereits vor zehn Minuten begonnen hat, was eine reine Momentaufnahme nicht zeigen kann. glances rechtfertigt den Zusatzaufwand vor allem dann, wenn mehrere Server zentral überwacht werden sollen, ohne für jeden einzelnen eine interaktive SSH-Session zu öffnen.

In minimalen Container-Images ohne Paketmanager, etwa Distroless- oder Scratch-Images, ist selbst htop oft nicht verfügbar. Hier ist entweder ein statisch gelinktes Binary vorab ins Image zu kopieren, oder man verlässt sich auf das eingebaute BusyBox-top, das deutlich weniger Funktionsumfang bietet als das GNU-Pendant. Für Teams, die Monitoring standardisieren wollen, ist die REST-API von glances zudem der pragmatischste Weg, um Kennzahlen automatisiert abzufragen, ohne eine vollständige Prometheus-Exporter-Pipeline aufzusetzen.

// GET http://webserver01:61208/api/4/cpu
// glances REST API response, polled by an external dashboard or script
{
  "total": 42.7,
  "user": 31.2,
  "system": 9.8,
  "idle": 57.3,
  "iowait": 1.5,
  "steal": 0.2,
  "cpucore": 4,
  "ctx_switches": 184213,
  "interrupts": 92104,
  "time_since_update": 3.01
}

9. Praktischer Live-Incident-Workflow: von Alarm bis Root Cause

Ein strukturierter Workflow verhindert, dass man sich während eines Vorfalls in einzelnen Prozesszeilen verliert. Der erste Schritt nach dem Login ist immer uptime gefolgt von nproc, um die Load sofort ins Verhältnis zur Kernanzahl zu setzen. Direkt danach liefert ein nicht-interaktiver Snapshot mit top -b -n 1 -o %CPU eine dokumentierbare, script-freundliche Momentaufnahme, die sich auch in eine Log-Datei umleiten lässt, bevor man überhaupt interaktiv wird. Zeigt dieser Snapshot einen klaren CPU-Ausreißer, wechselt man in htop, aktiviert die Baumansicht mit F5 und bei Multithread-Verdacht zusätzlich die Thread-Ansicht mit Shift+H.

Liegt der Verdacht stattdessen bei I/O-Wartezeit, also einem hohen wa-Wert in der Kopfzeile, filtert man gezielt auf Prozesse im Zustand D und prüft parallel iostat -x 1 auf überlastete Block-Devices. Erst wenn Prozessliste und Ressourcenwerte einen konkreten Kandidaten liefern, folgt die Tiefenanalyse mit strace -p oder lsof -p, um den genauen Systemaufruf oder die blockierte Datei zu identifizieren. Bei verteilten Systemen dokumentiert glances --export csv während des Vorfalls automatisch einen Verlauf, der im Nachgang für die Root-Cause-Analyse und den Incident-Report verwendet werden kann, statt sich auf das Gedächtnis der beteiligten Personen zu verlassen.

# Step-by-step live incident workflow
uptime && nproc

# 1) Non-interactive, loggable snapshot first
top -b -n 1 -o %CPU | tee -a /var/log/incident-2026-07-12.log

# 2) Drill into the tree view interactively if a clear offender is visible
htop   # then F5 for tree view, Shift+H for per-thread view

# 3) If I/O-wait dominates, check block device saturation
iostat -x 1 5

# 4) Deep dive once a candidate PID is identified
strace -p 18422 -f -tt
lsof -p 18422 | head -n 20

# 5) Keep a running export for the post-incident report
glances --export csv --export-csv-file /var/log/glances-incident.csv

Die folgende Tabelle stellt für die häufigsten Monitoring-Aufgaben das riskante beziehungsweise ungenaue Vorgehen dem empfohlenen Ansatz gegenüber.

10. Zusammenfassung

Verlässliches System-Monitoring beginnt mit der korrekten Lesart der Grundwerte: Die Load Average muss immer im Verhältnis zur Kernanzahl bewertet werden und zählt unter Linux auch I/O-wartende Prozesse mit. Die Kopfzeilen von top und htop liefern mit %Cpu(s), Mem und Swap bereits einen Großteil der Diagnose, bevor überhaupt eine einzelne Prozesszeile betrachtet wird. Bei den Speicherwerten gilt: RES-Werte mehrerer Prozesse nicht addieren, sondern mit PSS über smem oder smaps_rollup die tatsächliche Belegung ermitteln.

Gezieltes Sortieren nach CPU oder Speicher und die Thread-Ansicht mit H beziehungsweise Shift+H führen zuverlässig zum tatsächlichen Übeltäter, statt Zeit mit manuellem Scrollen zu verschwenden. Moderne Alternativen wie btop und glances lohnen sich, sobald historische Verläufe oder zentrales Monitoring über mehrere Server hinweg gefragt sind, während top und htop für die schnelle Einzelserver-Diagnose weiterhin die zuverlässigste Grundausstattung bleiben. Ein strukturierter Workflow von Snapshot über Baumansicht bis zur Tiefenanalyse mit strace spart in einem akuten Vorfall entscheidende Minuten.

11. FAQ: System-Monitoring mit top, htop und Alternativen