Linux-CPU-Monitoring-Metriken: Der vollständige Leitfaden für Sysadmins

Sie melden sich auf einem Linux-Server an, starten top, sehen die CPU bei 45 % – alles im grünen Bereich, denken Sie. Zwei Stunden später haben sich die Antwortzeiten verdoppelt, und endlich feuert ein Alert. Was haben Sie übersehen?

CPU-Auslastung allein ist eine der am häufigsten fehlinterpretierten Zahlen im Linux-Server-Monitoring. Ein System bei 45 % kann auf einem einzelnen Core bereits saturiert sein, während sieben weitere im Leerlauf liegen. Ein System bei 90 % kann dagegen kerngesund sein, sofern es echte Arbeit verrichtet und die Last konstant bleibt. Linux-CPU-Monitoring-Metriken richtig zu lesen heißt zu wissen, welche Zahlen Sie betrachten müssen, was jede einzelne tatsächlich misst und welcher Schwellenwert Sie um 3 Uhr morgens aus dem Bett klingeln sollte.

Dieser Leitfaden geht die zentralen Linux-CPU-Metriken durch, die jeder Sysadmin und DevOps-Engineer im Blick haben sollte – samt empfohlener Schwellenwerte, der wichtigsten Tools und einem Entscheidungsbaum für die Triage von High-CPU-Alerts.

Warum Linux-CPU-Metriken wichtig sind

CPU ist die billigste Ressource im Monitoring und die teuerste, wenn man sie falsch liest. Eine einzige fehlinterpretierte Grafik kann einen On-Call-Engineer um Mitternacht in das falsche Subsystem schicken, während der eigentliche Engpass auf der Disk oder im Hypervisor liegt.

Ein nützliches Modell ist die USE-Methode, popularisiert von Brendan Gregg: Betrachten Sie jede Ressource entlang von Utilization (Auslastung), Saturation (Sättigung) und Errors (Fehler). CPU-Metriken passen sauber in dieses Schema. Die Auslastung zeigt, was die CPU gerade tut. Die Sättigung – Load Average, Run Queue Length, Context Switches – verrät, ob mehr Arbeit wartet, als verarbeitet werden kann. Fehler sind auf CPU-Ebene selten und tauchen als Machine Checks in dmesg auf.

Mit der richtigen Kombination aus Utilization- und Saturation-Metriken im kontinuierlichen Linux-Server-Monitoring reagieren Sie nicht mehr auf Ausfälle, sondern verhindern sie.

Die zentralen Linux-CPU-Metriken, die Sie überwachen sollten

Diese Metriken gehören auf jeden Linux-Server. Jede einzelne erzählt einen anderen Teil der Geschichte – zusammengenommen ergeben sie das vollständige Bild.

CPU-Auslastung (us, sy, ni, id, wa, hi, si, st)

Wenn top oder mpstat die CPU-Nutzung ausgeben, teilen sie die Gesamtzeit in acht Kategorien auf. Der Kernel führt diese Werte in /proc/stat, und jedes Monitoring-Tool liest letztlich von dort.

Feld	Name	Was es misst
`us`	user	Zeit in User-Space-Prozessen (Ihre Anwendungen)
`sy`	system	Zeit im Kernel-Space (Syscalls, Scheduling)
`ni`	nice	Zeit für User-Prozesse mit angepasster Priorität
`id`	idle	Zeit, in der die CPU nichts getan hat
`wa`	iowait	Leerlauf im Warten auf Disk- oder Netzwerk-I/O
`hi`	hardware IRQ	Bearbeitung von Hardware-Interrupts
`si`	software IRQ	Bearbeitung von Softirqs (häufig Netzwerk-Paketverarbeitung)
`st`	steal	Zeit, die der Hypervisor Ihrer VM weggenommen hat

Die Gesamt-CPU-Nutzung ist 100 - id, aber der diagnostische Wert steckt in der Aufschlüsselung. Hoher us-Anteil deutet auf Ihren Anwendungscode hin. Hoher sy-Anteil zeigt auf den Kernel – exzessive Forks, Syscalls oder Interrupt-Stürme. Hoher wa-Anteil ist überhaupt kein CPU-Problem; die CPU ist im Leerlauf und wartet auf langsame I/O. Auf jeden dieser Werte kommen wir im Entscheidungsbaum weiter unten zurück.

Load Average (1, 5, 15 Minuten)

Load Average ist die am meisten missverstandene Zahl auf einem Linux-System. Sie ist keine CPU-Auslastung. Speziell unter Linux zählt sie die Anzahl der Tasks, die entweder gerade auf einer CPU laufen oder im uninterruptible Sleep warten (typischerweise blockiert durch I/O).

Die drei Zahlen sind exponentiell gewichtete gleitende Mittelwerte über die letzten 1, 5 und 15 Minuten. Lesen Sie sie als Trend:

1m > 5m > 15m: Last steigt
1m < 5m < 15m: Last sinkt
Alle drei ungefähr gleich: stabiler Zustand

Die klassische Faustregel: Vergleichen Sie den Load Average mit der Anzahl der CPU-Cores. Ein 1-Minuten-Load von 4 auf einem 4-Core-System bedeutet, dass die CPU voll ausgelastet ist. Ein 1-Minuten-Load von 12 auf demselben System heißt, dass etwa 8 Tasks Schlange stehen – Sättigung.

$ uptime
 14:22:01 up 47 days, load average: 6.42, 3.18, 1.75

Wenn diese Maschine 4 Cores hat, ist der Trend schlecht, und die 1-Minuten-Zahl signalisiert: Sie sind bereits saturiert.

Run Queue Length

Run Queue Length, von vmstat als r ausgegeben, ist die Anzahl der Tasks, die aktuell auf CPU-Zeit warten. Anders als der Load Average schließt sie I/O-blockierte Tasks aus – sie ist also ein sauberes Sättigungssignal speziell für die CPU.

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0      0 1.2G    1.1G   3.4G    0    0     0     0  9.2k 14k 71  6 22  1  0

Ein dauerhaftes r über der Core-Anzahl bedeutet, dass sich eine Warteschlange bildet – Ihre CPU ist zum Engpass geworden, und entweder muss Kapazität nachgerüstet oder der heiße Prozess identifiziert werden. Die Run Queue steigt häufig bevor die Auslastung einen einzelnen Core sättigt – das macht sie zu einem nützlichen Frühindikator.

Context Switches und Interrupts

Context Switches (cs in vmstat) sind die Anzahl der Wechsel pro Sekunde, mit denen der Kernel von einem Prozess oder Thread auf einen anderen umschaltet. Interrupts (in) sind die vom Kernel verarbeiteten Hardware- und Software-Interrupts.

Es gibt keine universelle „gute" Zahl – beide hängen stark vom Workload ab. Ein ausgelasteter Netzwerk-Server kann durchaus 50.000 oder mehr Context Switches pro Sekunde produzieren. Was zählt, ist die Veränderung über die Zeit: Ein plötzlicher Anstieg der Context Switches ohne entsprechende Workload-Änderung deutet oft auf Lock-Contention, schlecht konfigurierte Thread-Pools oder einen Runaway-Prozess hin, der zwischen Threads hin- und herspringt.

Beobachten Sie diese Werte als Trends. Alarmieren Sie auf Rate-of-Change, nicht auf absolute Schwellen.

I/O-Wait (iowait)

wa verdient einen eigenen Abschnitt, weil es die Metrik ist, die am häufigsten zu Unrecht beschuldigt wird. Hoher iowait bedeutet: Die CPU ist im Leerlauf und wartet auf Disk oder Netzwerk. Die CPU selbst ist nicht das Problem – Ihr Storage oder Ihr Netzwerk ist es.

Liegt iowait dauerhaft über 10–20 %, springen Sie direkt zu den Disk-Metriken: Queue Depth, Await-Zeit und IOPS. Die Lösung lautet so gut wie nie „mehr CPU hinzufügen". Sie lautet fast immer „den Storage-Layer untersuchen" – langsame Disks, ein gesättigter Controller oder eine Anwendung, die zu viele kleine Reads ausführt.

Steal Time auf Cloud und VPS

Steal Time (st) ist die Zeit, in der Ihre virtuelle CPU lauffähig war, der Hypervisor den physischen Core aber an eine andere VM vergeben hat. Auf Bare Metal ist die Steal Time immer null. Auf AWS, DigitalOcean, Hetzner Cloud, Vultr oder jeder anderen geteilten Virtualisierungs-Plattform ist sie eine der wichtigsten Linux-CPU-Monitoring-Metriken, die Sie überhaupt erfassen können.

Zwei Muster sollten Sie kennen:

Anhaltende niedrige Steal Time (1–3 %) ist normales Hintergrundrauschen auf geteilten Cloud-Instanzen. Ignorieren Sie es.
Anhaltende hohe Steal Time (über 10 %) bedeutet: Sie sind Opfer eines Noisy Neighbour, Sie haben die CPU-Credits einer Burstable Instance aufgebraucht (T-Serie auf AWS), oder Ihr Account wird gedrosselt. Migrieren Sie auf einen dedizierten Instance-Typ oder eröffnen Sie ein Ticket beim Provider.

Wenn Sie auf Cloud- oder VPS-Infrastruktur laufen, alarmieren Sie auf Steal Time. Sie fängt Probleme ab, die Sie sonst auf keinem anderen Weg diagnostizieren können.

Empfohlene Schwellenwerte und Alerts

Die Metriken zu kennen ist die halbe Arbeit. Zu wissen, wann sich ein Alert lohnt – ohne Ihre On-Call-Rotation in Lärm zu ertränken – ist die andere Hälfte.

Metrik	Warnung	Kritisch	Hinweise
CPU-Auslastung (`100 - id`)	> 80 % über 5 Min.	> 95 % über 5 Min.	Pro Core; Aggregat versteckt Single-Thread-Sättigung
Load Average (1m)	> 1,0 × Cores	> 2,0 × Cores	Mit Core-Anzahl vergleichen, nicht absolut
Run Queue (`vmstat r`)	> Cores	> 2 × Cores	Über 2+ Minuten konstant
iowait (`wa`)	> 10 %	> 20 %	Disk untersuchen, nicht CPU
Steal Time (`st`)	> 5 %	> 10 %	Nur Cloud/VPS; Bare Metal sollte 0 sein
Context Switches	> 2× Baseline	> 5× Baseline	Auf Abweichung alarmieren, nicht absolut

Zwei Prinzipien halten das Alert-Volumen erträglich:

Anhaltend, kein kurzer Spike. Ein Load Average von 50 über eine Sekunde sagt fast nichts aus – das System könnte gerade einen Build laufen lassen. Verlangen Sie, dass der Schwellenwert 2–5 Minuten gehalten wird, bevor alarmiert wird.
Pro Core für die Auslastung, Aggregat für den Rest. Ein Single-Thread-Job, der einen Core auf 100 % nagelt, taucht auf einem Aggregat-Dashboard nie als Problem auf. Wenn Sie nur auf Gesamt-CPU-Prozente alarmieren, übersehen Sie diesen Fall jedes Mal.

Tools für die Erfassung von Linux-CPU-Metriken

Es gibt drei Tooling-Schichten mit jeweils unterschiedlicher Rolle.

Eingebaute Kommandos

Jede Linux-Distribution bringt die Basics mit. Diese sollten im Muskelgedächtnis sitzen:

top / htop – interaktive Echtzeit-Ansicht; htop zeigt Ihnen mit 1 Balken pro Core
mpstat -P ALL 1 – Aufschlüsselung pro CPU, Refresh jede Sekunde
vmstat 1 – Run Queue, Context Switches, Interrupts plus Memory und I/O
sar -u 1 5 – historische und Live-CPU-Statistiken; sar speichert mit aktiviertem sysstat Tage an Verlauf
pidstat 1 – CPU-Nutzung pro Prozess über die Zeit

Diese sind perfekt für die Live-Fehlersuche. Für Trend-Analysen, Alerting oder Post-Incident-Reviews sind sie unbrauchbar, weil sie nichts persistieren.

Direkt aus /proc/stat lesen

Wer einen eigenen Collector schreibt, findet die Quelle der Wahrheit in /proc/stat:

$ cat /proc/stat | head -1
cpu  3429847 1209 891234 87234521 12834 0 4521 8210 0 0

Die Felder sind user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice – in Jiffies (typischerweise 1/100 Sekunde). Zweimal sampeln, subtrahieren, dividieren – fertig ist die Rate. Genau das macht jeder Monitoring-Agent unter der Haube.

Agentenbasiertes Monitoring

Sobald Sie über die Live-Fehlersuche auf einem einzelnen Host hinausgehen, brauchen Sie einen Agenten. Der Agent sampelt Metriken planmäßig, schickt sie an ein zentrales System, speichert sie für die Trend-Analyse und feuert Alerts gegen Ihre Schwellenwerte. Moderne Optionen sind Prometheus mit node_exporter, der Grafana Agent, Datadog – und unser eigenes Xitogent, ein schlanker Agent, der jede Metrik aus diesem Leitfaden automatisch erfasst und ohne manuelle Konfiguration an Xitoring überträgt.

Der Agent ist das, was CPU-Monitoring von „Ich habe nachgesehen, als mir etwas auffiel" zu „Ich werde gepiept, sobald etwas vom Normalzustand abweicht" macht.

Pro Core vs. Aggregat: Die Single-Thread-Falle

Ein Szenario, das wir oft sehen: Ein 8-Core-Server lässt stündlich ein altes Report-Generierungs-Skript laufen. Das Skript ist single-threaded. Während es läuft, sitzt ein Core 12 Minuten lang auf 100 %. Die Gesamt-CPU auf dem Dashboard zeigt 12,5 % – weit innerhalb jeder vernünftigen Schwelle. Kein Alert. Aber die Antwortzeiten für jede Anfrage, die auf diesem festgenagelten Core landet, schnellen hoch, und Kunden beschweren sich.

Die Lösung ist im Prinzip einfach: Alarmieren Sie auf Per-Core-Auslastung, nicht nur auf das Aggregat. In der Praxis bedeutet das, mpstat -P ALL für die Live-Diagnose zu nutzen und den Monitoring-Agenten so zu konfigurieren, dass er Per-CPU-Statistiken erfasst und auf jeden einzelnen Core alarmiert, der dauerhaft über 95 % bleibt.

Genau deshalb gehört die CPU-Auslastung am besten gemeinsam mit der Run Queue Length beobachtet – selbst wenn das Aggregat das Problem verschleiert, gibt eine Warteschlange hinter dem festgenagelten Core eine zweite Chance, es zu erkennen.

Ein Entscheidungsbaum für High-CPU-Alerts

Wenn um 3 Uhr morgens ein CPU-Alert feuert, brauchen Sie ein Skript, das Sie im Kopf abarbeiten können. Lesen Sie die Aufschlüsselung – us, sy, wa, st – und folgen Sie dem passenden Zweig:

us (user) ist hoch → Es ist Ihr Anwendungscode. top nach %CPU sortieren, den Prozess identifizieren, dann mit pidstat -t -p <PID> 1 den Thread bestimmen. Den heißen Code-Pfad profilen.
sy (system) ist hoch → Es ist der Kernel. Wahrscheinliche Schuldige: ein Runaway-Prozess, der permanent forkt (pidstat -w 1 zeigt Context Switches pro Prozess), ein Netzwerk-Interface unter Paketflut (Softirq-Zeit und /proc/softirqs prüfen) oder außer Kontrolle geratene Filesystem-Operationen.
wa (iowait) ist hoch → Es ist nicht die CPU, es ist der Storage. iostat -x 1 ausführen. %util, await und Queue Depth betrachten. Die CPU ist im Leerlauf und wartet; untersuchen Sie Disks, den Storage-Controller oder das, was die Anwendung gerade liest.
st (steal) ist hoch → Es ist der Hypervisor. Sie laufen auf Cloud oder VPS. Entweder sind Ihre Burstable Credits aufgebraucht, der Host ist überbucht, oder ein Noisy Neighbour beansprucht denselben physischen Core. Workloads auf einen dedizierten Instance-Typ umziehen oder den Provider kontaktieren.
Alle vier wirken normal, aber der Load Average ist hoch → Etwas hängt im uninterruptible Sleep (D-State). ps -eo state,pid,comm | grep ^D ausführen. Fast immer Disk- oder NFS-bezogen.

Bewahren Sie diese Tabelle dort auf, wo die On-Call-Bereitschaft sie findet. Sie verwandelt einen panischen Alert in eine fünfminütige Untersuchung.

Linux-CPU-Metriken überwachen mit Xitoring

Wenn Sie Collector, Dashboards und Alerting nicht selbst zusammenstricken wollen, übernimmt das Xitoring direkt von Haus aus. Installieren Sie Xitogent mit einem Einzeiler auf einem beliebigen Linux-Host – innerhalb weniger Minuten wird jede Metrik aus diesem Leitfaden erfasst und grafisch aufbereitet: CPU-Aufschlüsselung, Load Average, Run Queue, iowait, Steal Time, Per-Core-Auslastung.

Schwellenwert-Alerts kommen mit den Werten aus der Tabelle oben vorkonfiguriert, und Sie können sie an Slack, Microsoft Teams, PagerDuty, Opsgenie, Telegram oder jeden anderen unserer Benachrichtigungskanäle ausspielen. Wenn ein CPU-Alert feuert, enthält die Benachrichtigung die Aufschlüsselung – Sie wissen also schon vor dem Öffnen des Dashboards, ob Sie User-Code, den Kernel oder einen lärmenden Hypervisor verdächtigen müssen.

Starten Sie eine kostenlose Testphase und haben Sie das kontinuierliche Linux-CPU-Monitoring in unter fünf Minuten über Ihre gesamte Flotte ausgerollt.

FAQs

Was ist eine normale CPU-Nutzung auf einem Linux-Server?

Es gibt keine universelle Normalität. Ein Webserver, der nachts vor sich hin idlet, kann bei 5 % liegen; derselbe Server unter Spitzenlast kann dauerhaft 70–80 % verkraften und dabei kerngesund sein. Entscheidend ist, ob der Workload rechtzeitig bedient wird – stimmt die Antwortlatenz, ist hohe CPU-Auslastung kein Problem. Alarmieren Sie auf anhaltende Auslastung über 80–95 % in Kombination mit steigendem Load Average und wachsender Queue Length.

Was ist der Unterschied zwischen Load Average und CPU-Nutzung?

CPU-Nutzung ist der Prozentanteil der Zeit, in der die CPU beschäftigt war. Load Average ist die Anzahl der Tasks, die laufen oder darauf warten zu laufen, inklusive der durch I/O blockierten Tasks (uninterruptible Sleep). Ein System kann niedrige CPU-Nutzung und hohen Load Average gleichzeitig zeigen, wenn Prozesse auf langsame Disks oder Netzwerk warten – das ist ein Last-Problem, aber kein CPU-Problem.

Wie überwache ich die CPU-Nutzung pro Core unter Linux?

Die schnellste Live-Ansicht ist mpstat -P ALL 1. In htop schalten Sie mit der Taste 1 auf Balken pro Core um. Für kontinuierliches Monitoring konfigurieren Sie Ihren Agenten so, dass er Per-CPU-Statistiken erfasst – Xitogent tut das standardmäßig – und alarmieren auf jeden einzelnen Core, der dauerhaft über 95 % bleibt.

Was bedeutet Steal Time auf AWS oder DigitalOcean?

Steal Time ist der Prozentanteil der Zeit, in der Ihre VM lauffähig war, der Hypervisor die physische CPU aber an eine andere VM vergeben hat. Auf AWS-T-Serie-Instanzen heißt das in der Regel: Ihre CPU-Credits sind verbraucht. In jeder Cloud kann es einen Noisy Neighbour oder einen überbuchten Host bedeuten. Anhaltende Steal Time über 10 % ist ein starkes Signal, hochzustufen oder zu migrieren.

Auf welche Linux-CPU-Monitoring-Metriken sollte ich alarmieren?

Mindestens: CPU-Auslastung pro Core, Load Average im Verhältnis zur Core-Anzahl, iowait und Steal Time. Ergänzen Sie die Run Queue Length, wenn Sie einen Frühindikator wollen, bevor die Auslastung saturiert. Setzen Sie auf anhaltende Schwellenwerte (5+ Minuten), um Alert-Fatigue durch transiente Spikes zu vermeiden.

Fazit

Linux-CPU-Monitoring-Metriken sind nur dann nützlich, wenn Sie sie in Kombination lesen. Die Auslastung sagt Ihnen, dass die CPU beschäftigt ist. Load Average und Run Queue sagen Ihnen, dass sie saturiert ist. Die Aufschlüsselung in user/system/iowait/steal sagt Ihnen warum – Anwendungscode, Kernel, Storage oder Hypervisor. Alert-Schwellen verwandeln die Daten in Handlung, und der richtige Agent verwandelt die Handlung in eine Grafik und eine Benachrichtigung, bevor Kunden überhaupt etwas merken.

Wenn Sie bereit sind, kontinuierliches CPU-Monitoring in Ihrer Linux-Flotte aufzusetzen, sehen Sie sich an, wie das Linux-Server-Monitoring von Xitoring das löst, oder lesen Sie weiter zu warum Metriken-Monitoring für die Uptime entscheidend ist und zu Best Practices für das Aufsetzen von Server-Monitoring.