Monitoring in der Shell: top, htop, btop, iftop und GPU-Tools unter Debian 13 und CachyOS

Abtastung, Zähler und die richtige Frage

Alle Werkzeuge in diesem Artikel fallen in zwei Gruppen, und die Wahl entscheidet mehr als die Optik: Zähler lesen fortlaufende Kernel-Werte (aufsummierte Ticks, Bytes, Pakete) und lassen sich beliebig oft abfragen – ss, nstat, /proc/net/dev, /sys/fs/cgroup. Abtaster bauen aus zwei Zählerständen eine Rate, brauchen ein Zeitintervall und liefern Momentaufnahmen – top, htop, btop, iftop, iostat.

Praktisch wichtig ist außerdem ein Unterschied, der in der Doku selten so klar steht: Interaktive TUIs brauchen ein echtes Terminal. Ohne tty beendet sich htop mit einer klaren Meldung:

htop -n 1 | head
ncurses: cannot initialize terminal type ($TERM="unknown"); exiting

Genau dort endet der Weg für Cronjobs und Skripte – und genau deshalb beginnt dieser Artikel mit top, das als einziges der großen TUIs einen echten Batch-Modus hat.

Installation: Debian 13 und CachyOS

Auf dem Testsystem (CachyOS) waren top, htop, btop, glances, nvtop, sensors, cpupower, duf und ncdu bereits vorhanden – amdgpu_top, nvitop, iotop, atop und sysstat nicht. Die Versionsunterschiede zwischen Debian 13 und Arch sind bei diesen Werkzeugen erheblich:

# Debian 13: die Basis plus Spezialisten
sudo apt install procps htop btop glances nvtop iotop atop sysstat nmon s-tui \
                 lm-sensors turbostat duf ncdu powertop intel-gpu-tools

# CachyOS / Arch: dieselbe Liste, andere Namen
sudo pacman -S htop btop glances nvtop amdgpu_top radeontop iotop atop sysstat \
               nmon s-tui lm_sensors turbostat duf ncdu powertop intel-gpu-tools

top: der Alleskönner mit Batch-Modus

top ist auf jedem Server, weil es zu procps gehört. Sein Alleinstellungsmerkmal unter den TUIs ist der Batch-Modus -b: Damit landen Ausgaben in Logs, Mails oder Skripten – das ist die Grundlage jeder simplen Eigenüberwachung.

# Momentaufnahme, eine Sekunde später, nur die CPU-Zeile und die Top-Prozesse
top -b -n1 | head -12

top - 01:30:33 up  1:11,  1 user,  load average: 0,28, 0,52, 0,77
Tasks: 4 total, 1 running, 3 sleep, 0 d-sleep, 0 stopped, 0 zombie
%CPU(s):  0,3 us,  0,2 sy,  0,0 ni, 99,5 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:  94033,4 total,  63989,7 free,  12943,5 used,  19468,6 buff/cache
MiB Swap:  94033,0 total,  94029,1 free,      3,9 used.  81089,9 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
      1 ba0       16  -4    1052    312    264 S   0,0   0,0   0:00.00 apply-s+
      2 ba0       16  -4    8904   4132   3808 S   0,0   0,0   0:00.00 bash

Für eine schlanke Eigenüberwachung reicht schon eine Zeile, die per Cron oder systemd-Timer läuft und nur dann etwas schreibt, wenn es auffällt – hier die Top-5 nach Speicher:

# Die fünf speicherhungrigsten Prozesse, ohne Kopfzeilen
top -b -n1 -o %MEM | sed -n '7,11p'

# Nur das Wichtigste in eine Datei, für einen Tagesverlauf
top -b -n1 -o %CPU | head -12 >> /var/log/meine-cpu-momente.log

top-Ausgaben lesen

Die erste Zeile ist die meistmissverstandene. load average zählt nicht nur laufende Prozesse, sondern auch solche, die auf I/O warten – auf einem 16-Kern-System ist eine Last von 4 deshalb kein Alarm, auf einem 1-Kern-VPS schon.

htop: Bedienung und Filter

htop ist die komfortable Alternative: farbige Balken, Prozessbaum, Maus-Support und – für Server wichtiger – Filter und Sortierung per Kommandozeile. Das ist der Unterschied zwischen „ich suche" und „ich weiß schon wonach":

# hilfreiche htop-Optionen (3.5.x)
htop -p 1,4711 -d 5          # nur diese PIDs, alle 0,5 Sekunden
htop -u www-data             # nur Prozesse eines Benutzers
htop -F nginx                # nur Kommandos, die "nginx" enthalten
htop -s PERCENT_MEM          # Sortierung schon beim Start
htop -t -s PERCENT_CPU       # Baumansicht, nach CPU sortiert
htop --readonly              # ohne Kill-/Renice-Funktionen
htop -n 5                    # nach 5 Bildern beenden (braucht ein Terminal)

Die Einstellungen landen in ~/.config/htop/htoprc; Ressourcenlimits bei Resource limits, die Spaltenauswahl bei Options → Columns. Ein Detail, das auf Produktivsystemen hilft: htop --readonly verhindert versehentliche Signale, und htop -u www-data -s PERCENT_CPU beantwortet die Frage „was macht der Web-User?“ in einem Aufruf.

btop: Grafik, Presets, GPU-Anzeige

btop ist das optisch stärkste Werkzeug der Reihe und zeigt neben CPU, Speicher und Platte auch Netzwerk und – je nach Hardware – GPU-Auslastung. Auf dem Testsystem läuft 1.4.7; die Konfiguration liegt in ~/.config/btop/btop.conf, und die Standardwerte lassen sich komplett ausgeben, ohne den TUI zu starten:

btop --default-config | grep -E '^(preset|shown_boxes|update_ms|proc_sorting|show_gpu_info|net_auto|temp_scale)'

presets = "cpu:1:default,proc:0:default cpu:0:default,mem:0:default,net:0:default cpu:0:block,net:0:tty"
shown_boxes = "cpu mem net proc"
update_ms = 2000
proc_sorting = "cpu lazy"
show_gpu_info = "Auto"
net_auto = true
temp_scale = "celsius"

Zwei Hinweise aus der Praxis: btop ist in C++ geschrieben und deutlich sparsamer als der Python-Vorgänger bpytop – auf schwachen VPS ist das der Unterschied zwischen „Tool vertretbar“ und „Tool ist das Problem“. Und: Wer die GPU-Zeile sehen will, sollte show_gpu_info auf On stellen, wenn die Erkennung Auto die Karte nicht findet – btop liest AMD-Werte direkt aus /sys, NVIDIA-Werte über NVML.

glances: die eierlegende Wollmilchsau

glances hat einen entscheidenden Vorteil gegenüber allen anderen TUIs: es kann ohne Terminal Daten liefern – als Text, JSON oder CSV. Damit ist es das Bindeglied zwischen „ich schaue mal“ und „ich überwache dauerhaft“:

# Einmalige Ausgabe als Text (echte Werte vom Testsystem)
glances --stdout cpu,mem,load

cpu: {'total': 1.1, 'user': 1.7, 'nice': 0.0, 'system': 0.5, 'idle': 95.9,
      'iowait': 1.8, 'irq': 0.1, 'steal': 0.0, 'cpucore': 32}
mem: {'total': 98601197568, 'available': 84968353792, 'percent': 13.8,
      'used': 13632843776, 'cached': 19621306368}
load: {'min1': 0.31, 'min5': 0.51, 'min15': 0.76, 'cpucore': 32}

Weil glances in Python geschrieben ist, kostet es mehr CPU als btop – auf einem kleinen VPS merkt man das. Dafür ist die Web-Oberfläche (-w) die schnellste Art, einem Kollegen „schau mal selbst“ zu sagen, ohne ihm SSH-Zugang zu geben: Die Werte kommen aus derselben Sammlung wie im Terminal.

Die Spezialisten: iotop, atop, sysstat, nmon

Wenn top nur noch iowait anzeigt und nicht den Verursacher, kommen die Spezialisten ins Spiel. Sie beantworten je eine Frage richtig, statt alles ein bisschen zu zeigen.

# Nur aktive I/O-Prozesse, kumulierte Werte (Batch-tauglich mit -b)
sudo iotop -oPa
sudo iotop -b -o -n 3 -d 5

# atop: Live-Ansicht, Historie einsehen, Batch-Modus
sudo atop
sudo atop -r /var/log/atop/atop_20260921
sudo atop -b -n 1

# sysstat: Momentaufnahmen und Verlauf
iostat -xz 1 5            # Platten: Auslastung, Warteschlangen, Latenz
mpstat -P ALL 1 3         # pro Kern
pidstat -p 4711 1 5       # ein einzelner Prozess über 5 Sekunden
sar -u 1 3                # CPU-Verlauf (live, wenn Timer aktiv)
sar -n DEV -f /var/log/sysstat/sa21   # Netzwerk von gestern (Pfad je Distribution)

Netzwerk: iftop, nethogs, bandwhich

iftop beantwortet eine Frage sehr gut: welche Verbindung ist gerade laut? Dafür sortiert es live nach Bandbreite – pro Host-Paar, nicht pro Prozess. Es braucht wie tcpdump das Recht auf Rohpakete, sonst endet der Start mit einer klaren Meldung:

iftop -n -B -i enp17s0
pcap_open_live(enp17s0): enp17s0: You don't have permission to perform this capture
on that device (Attempt to create packet socket failed - CAP_NET_RAW may be required)

Wenn die Frage dagegen „welcher Prozess zieht die Leitung?“ lautet, hilft iftop nicht weiter: Ihm fehlt die Prozesszuordnung. Dafür gibt es nethogs und bandwhich, die pro Prozess summieren:

sudo nethogs enp17s0        # Bandbreite pro Prozess
sudo bandwhich              # Prozess + Verbindung + DNS-Name

Für den Überblick ohne Rechte reichen die Kernel-Zähler: ip -s link, /proc/net/dev und nload (das ohne Sonderrechte auskommt, weil es nur /proc/net/dev liest). Wer die Paketebene braucht, ist bei tcpdump und Netzwerk-Monitoring richtig – dort stehen Filter, Mitschnitte und Rotation.

AMD-GPUs: amdgpu_top, radeontop und sysfs

AMD hat den Vorteil, dass der Treiber amdgpu alles über /sys veröffentlicht. Damit funktionieren die Werkzeuge ohne Hersteller-Bibliotheken – und man kann die Werte auch ohne Werkzeug lesen. Das Testsystem hat zwei AMD-Karten (0x1002:0x13c0 als iGPU und 0x1002:0x744c als dedizierte Karte), also zwei Einträge:

# Auslastung, VRAM, Leistungszustand und Sensorik direkt aus dem Kernel
for c in /sys/class/drm/card[0-9]; do
  echo "$(basename $c): busy=$(cat $c/device/gpu_busy_percent 2>/dev/null)% vram=$(cat $c/device/mem_info_vram_used 2>/dev/null) level=$(cat $c/device/power_dpm_force_performance_level 2>/dev/null)"
done

card0: busy=0% vram=445046784 level=auto
card1: busy=5% vram=2925887488 level=auto

Noch mehr Werte liefert die Sensorik über hwmon – Leistung in Mikrowatt, Temperatur in Milligrad:

cat /sys/class/drm/card1/device/hwmon/hwmon4/power1_average   # 30000000 = 30 W
cat /sys/class/drm/card1/device/hwmon/hwmon4/temp1_input      # 53000 = 53 °C

# amdgpu_top: Live-Ansicht, Liste der Geräte, Einzelwerte
amdgpu_top
amdgpu_top -l
amdgpu_top --gpu-metrics        # detaillierte Queue-Metriken

# radeontop: nur Auslastung, sehr leichtgewichtig
radeontop

# nvtop: alle GPUs, mit Prozessliste und Verlaufsgraph
nvtop -d 10 -p --gpu-info

NVIDIA: nvidia-smi und nvitop

Bei NVIDIA kommt die Information aus der Treiber-Bibliothek (NVML), nicht aus /sys. Das Standardwerkzeug ist nvidia-smi, das über --query-gpu skriptbare Ausgaben liefert – der wichtigste Aufruf für Überwachung ist der Dauerlauf:

# Momentaufnahme
nvidia-smi

# Skriptbare Felder, fortlaufend jede Sekunde (CSV)
nvidia-smi --query-gpu=timestamp,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw \
           --format=csv -l 1

# Wer nutzt die GPU? (Prozesse)
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

# nvitop: TUI mit Prozessbaum, Verlauf und Farbcodierung
nvitop -m auto --once           # einmalige Ausgabe (skriptbar)
nvitop                          # interaktive Ansicht

Intel: intel_gpu_top

Bei Intel-Grafik liefert intel_gpu_top (Paket intel-gpu-tools) die Auslastung getrennt nach Engines – Render, Blitter, Video, Video-Enhance. Es braucht Zugriff auf die Performance-Zähler:

# Debian 13
sudo apt install intel-gpu-tools

# CachyOS / Arch
sudo pacman -S intel-gpu-tools

# Live-Ansicht bzw. eine Momentaufnahme
sudo intel_gpu_top
sudo intel_gpu_top -l -s 1000      # Liste, jede Sekunde eine Zeile

Interessant ist das getrennte Lesen der Engines: Eine Videokonferenz lastet vor allem Video und VideoEnhance aus, ein Browser dagegen Render. Wer nur die Gesamtauslastung ansieht, sieht dort ein mittleres Rauschen und keine Ursache.

Takt, Temperatur und Leistung

sensors aus dem Paket lm-sensors ist auf beiden Distributionen die erste Adresse – und liefert auf dem Testsystem mehr als nur CPU-Werte: CPU (k10temp), beide GPUs (amdgpu), vier NVMe-Laufwerke und der Netzwerkchip erscheinen in einer Ausgabe. Zwei Aufrufe sind dafür wichtig:

sensors
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +65.8°C
Tccd1:        +47.1°C
Tccd2:        +44.4°C

# Dieselben Werte maschinenlesbar (JSON) – ideal für Skripte
sensors -j | head -c 300
{"k10temp-pci-00c3":{"Adapter":"PCI adapter","Tctl":{"temp1_input":68.375},
 "Tccd1":{"temp3_input":51.5},"Tccd2":{"temp4_input":66.625}}, …

Aus der JSON-Ausgabe des Testsystems lässt sich das gut ablesen: Die dedizierte AMD-Karte stand bei 53 °C Kanten- und 57 °C Junction-Temperatur, 72 °C Speicher, 518 U/min Lüfter, 34 W PPT bei 257 W Limit, Kern 183 MHz und Speicher 456 MHz im Ruhezustand. Genau das sind die Werte, die ein leerlaufender Server zeigen soll – verdächtig wird es, wenn sich im Ruhezustand Takt oder Leistung nach oben bewegen.

Druck statt Auslastung: PSI

Die wichtigste Neuerung im Linux-Monitoring der letzten Jahre steht in drei Dateien: /proc/pressure/cpu, /proc/pressure/memory und /proc/pressure/io. PSI (Pressure Stall Information) misst, wie viel Zeit Prozesse verloren haben, weil eine Ressource nicht verfügbar war – nicht, wie sehr sie ausgelastet ist:

for f in /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io; do echo "$f: $(cat $f)"; done

/proc/pressure/cpu: some avg10=0.00 avg60=0.00 avg300=0.00 total=5385586
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
/proc/pressure/memory: some avg10=0.00 avg60=0.00 avg300=0.00 total=1694
full avg10=0.00 avg60=0.00 avg300=0.00 total=1610
/proc/pressure/io: some avg10=1.82 avg60=3.30 avg300=3.57 total=135795517
full avg10=1.73 avg60=3.15 avg300=3.40 total=129768940

In der Beispielausgabe ist das Muster typisch: CPU und Speicher sind entspannt (0,00 %), während I/O bei 1,8 % „some“ und 1,7 % „full“ über 10 Sekunden liegt. Genau hier hilft PSI mehr als Load Average: Es zeigt eine I/O-Wartezeit, obwohl die Last mit 1,0 auf 32 Kernen völlig harmlos aussieht.

Container und cgroups

Auf einem Docker-Host ist die Prozessliste allein irreführend. systemd-cgtop ordnet die Last den systemd-Units und Slices zu – und hat einen Batch-Modus, der sich für Logs eignet:

systemd-cgtop -b -n1
/user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus…slice    608      -     7.9G        -        -

Dasselbe Prinzip steckt im cgroup-v2-Dateisystem, das man ohne zusätzliches Werkzeug lesen kann – hier echte Werte aus einem Container:

cat /sys/fs/cgroup/cpu.stat
usage_usec 2727884669
user_usec 2130360234
system_usec 597524434

cat /sys/fs/cgroup/memory.current    # aktuelle Belegung in Byte
cat /sys/fs/cgroup/memory.max        # Limit („max“ = unbegrenzt)
cat /sys/fs/cgroup/memory.pressure   # PSI für genau diese Gruppe

Speicher, Platte, Dateisysteme

Für Speicherfragen braucht es kein TUI. free -h beantwortet die Frage „wie viel ist wirklich frei?“ – wobei die Spalte verfügbar (available) die relevante ist, nicht frei:

free -h
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       91Gi        12Gi        62Gi       1,6Gi        19Gi        79Gi
Swap:           91Gi       3,9Mi        91Gi

vmstat 1 2 | tail -2
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 0  0   3980 65525452 807456 19128388  0   1  2749  2404 17379   7  1  0 98  0  0  0
 0  0   3960 65526556 807456 19128636 20   0    20   372 9302 10988 1  0 98  1  0  0

duf
│ MOUNTED ON       │   SIZE │   USED │  AVAIL │  USE% │ TYPE  │ FILESYSTEM     │
│ /                │ 463.8G │ 161.5G │ 300.2G │ 34.8% │ btrfs │ /dev/sdb2      │
│ /boot            │   2.0G │ 249.6M │   1.8G │ 12.2% │ vfat  │ /dev/sdb1      │

Der Blick auf die Dateisysteme lohnt sich auch bei Btrfs: duf zeigt die vom Kernel gemeldete Belegung – bei Btrfs ohne compsize also die tatsächlich belegten Blöcke, die je nach Kompression kleiner sein können als die Summe der Dateigrößen. Wer das auseinanderhalten will, schaut sich die Anteile in unserem Dateisystem-Vergleich an.

Fehlerbild → Werkzeug

Was hier nicht getestet wurde

Damit die Angaben einordenbar bleiben – geprüft heißt: in dieser Umgebung selbst ausgeführt:

Fazit

Die Shell ist kein Notbehelf, sondern für viele Fragen das schnellste Werkzeug: top für die Übersicht und für Logs, htop oder btop zum Arbeiten, glances für Automatisierung, iotop und iostat für Platten, iftop und nethogs fürs Netzwerk, die GPU-Tools für alles, was nicht CPU ist – und PSI für die Fälle, die alle anderen übersehen.