Um die Leistung eines Linux-Servers zu überwachen, prüfen Sie vier Ressourcen: CPU, Arbeitsspeicher, Disk-I/O und Netzwerk. Nutzen Sie für die Live-Fehlersuche integrierte Befehle wie top, vmstat, free, iostat und ss, und für Verlauf und Alarme ein agentenbasiertes Tool wie Prometheus mit node_exporter, Zabbix oder den CloudWatch Agent.
Das Wichtigste in Kürze
- Prüfen Sie pro Ressource Auslastung, Sättigung und Fehler (USE-Methode). Hohe Auslastung allein ist kein Problem; Warteschlangen und Fehler sind es.
- Vergleichen Sie die Load Average mit der Zahl der CPU-Kerne und beobachten Sie auf Cloud-VMs
%wa(I/O-Wartezeit) und%st(Steal Time). - Lesen Sie beim Arbeitsspeicher die Spalte
availablevonfree, nichtfree. Linux nutzt freien Speicher bewusst als Cache. - Die Pressure Stall Information in
/proc/pressure/zeigt direkt, wie viel Zeit Tasks auf CPU, Speicher oder I/O warten. - Befehle zeigen die Gegenwart. Für Trends und Alarme brauchen Sie einen Monitoring-Agenten und einen Zeitreihenspeicher.
Welche Linux-Leistungsmetriken sind wichtig?
Beginnen Sie mit der USE-Methode des Performance-Engineers Brendan Gregg: Prüfen Sie für jede Ressource Auslastung (Utilisation), Sättigung (Saturation) und Fehler (Errors). So haben Sie eine Checkliste statt Rätselraten.
| Ressource | Auslastung | Sättigung | Fehler | Befehle |
|---|---|---|---|---|
| CPU | %us, %sy pro Kern | Load Average über Kernzahl, Run Queue (r in vmstat), CPU-Pressure | Selten; dmesg auf Machine-Check-Fehler prüfen | top, mpstat -P ALL 1, vmstat 1 |
| Arbeitsspeicher | Belegt vs. available | Swap-in/-out (si/so), Speicher-Pressure, OOM-Kills | Meldungen des OOM-Killers im Kernel-Log | free -h, vmstat 1, journalctl -k |
| Datenträger | %util pro Gerät | Queue-Größe (aqu-sz), Wartezeit (r_await/w_await), I/O-Pressure | I/O-Fehler in dmesg, SMART-Warnungen | iostat -xz 1, df -h, df -i |
| Netzwerk | Durchsatz vs. Link- oder Instanzlimit | Verworfene Pakete, TCP-Retransmits | Schnittstellenfehler | sar -n DEV 1, ss -s, ip -s link |
Wie prüfen Sie CPU-Auslastung und Last unter Linux?
Starten Sie top (oder htop), lesen Sie die CPU-Zeile und vergleichen Sie die Load Average mit der Kernzahl aus nproc.
top # Live-Ansicht; mit 1 jeden Kern anzeigen
nproc # Anzahl der CPU-Kerne
uptime # Load Average über 1, 5 und 15 Minuten
mpstat -P ALL 1 # Auslastung pro Kern jede Sekunde (Paket sysstat)
Laut der Manpage proc_loadavg zählt die Load Average Jobs, die laufen oder auf Disk-I/O warten, gemittelt über 1, 5 und 15 Minuten. Eine Last von 6 auf einem Server mit 8 Kernen ist in Ordnung. Eine Last von 6 auf einem Server mit 2 Kernen heißt, dass Arbeit sich staut. Da die Last auch Prozesse einschließt, die auf den Datenträger warten, deutet eine hohe Last bei geringer CPU-Auslastung meist auf ein Storage-Problem.
In der CPU-Zeile von top sind auf Cloud-Servern zwei Felder wichtig:
wa: Zeit, in der die CPU untätig auf I/O wartete. Dauerhaft hohe Werte deuten auf langsame Datenträger oder Netzwerkspeicher.st: laut der Manpage von top die Zeit, die der Hypervisor dieser VM entzogen hat („time stolen from this vm by the hypervisor“). Dauerhafter Steal auf einer Cloud-VM heißt, dass der Host ausgelastet ist oder einer burstfähigen Instanz die CPU-Credits ausgegangen sind.
Wie prüfen Sie die Speichernutzung unter Linux?
Führen Sie free -h aus und lesen Sie die Spalte available. Die Manpage von free definiert sie als Schätzung des Speichers, der neuen Anwendungen ohne Swapping zur Verfügung steht, unter Berücksichtigung des Page Cache.
free -h # Speicherübersicht, menschenlesbar
vmstat 1 5 # Spalten si/so zeigen Swap-in/-out pro Sekunde
journalctl -k | grep -i "out of memory" # Ereignisse des OOM-Killers
Ein Server mit wenig „free“, aber reichlich „available“ Speicher ist gesund: Linux füllt freien RAM mit Disk-Cache und gibt ihn frei, wenn Programme ihn brauchen. Warnzeichen sind über Tage sinkender available-Speicher (ein mögliches Leck), dauerhafte Swap-Aktivität in vmstat und OOM-Killer-Einträge im Kernel-Log.
Wie prüfen Sie Datenträgerleistung und Speicherplatz?
Nutzen Sie iostat -xz 1 für die I/O-Leistung und df für Speicherplatz und Inodes.
iostat -xz 1 # Auslastung, Queue und Latenz pro Gerät (sysstat)
df -h # Speicherplatz pro Dateisystem
df -i # Inode-Nutzung: viele kleine Dateien füllen diese zuerst
du -sh /var/log/* | sort -h # herausfinden, was Platz belegt
Beobachten Sie in iostat die Werte r_await und w_await (durchschnittliche Millisekunden pro Anfrage) und aqu-sz (Queue-Länge). Die Manpage von iostat weist darauf hin, dass %util bei Geräten, die Anfragen parallel bedienen, etwa RAID-Verbünden und modernen SSDs, ihre Leistungsgrenzen nicht abbildet. Steigende Latenz und Queue-Länge sind bessere Zeichen für Sättigung.
Wie überwachen Sie die Netzwerkleistung?
sar -n DEV 1 # Durchsatz pro Schnittstelle
sar -n TCP,ETCP 1 # TCP-Verbindungen und Retransmits
ss -s # Zusammenfassung der Sockets
ip -s link # Fehler und Drops pro Schnittstelle
Steigende Retransmits, Drops oder Schnittstellenfehler weisen auf Netzwerkprobleme hin, auch wenn der Durchsatz normal aussieht. Vergleichen Sie auf Cloud-VMs den Durchsatz mit dem Netzwerklimit des Instanztyps.
Was ist Pressure Stall Information (PSI)?
PSI ist eine Kernel-Funktion, die meldet, wie viel Zeit Tasks mit Warten auf CPU, Speicher oder I/O verbringen. Die Kernel-Dokumentation erklärt, dass jede Datei in /proc/pressure/ eine „some“-Zeile hat (Zeitanteil, in dem zumindest einige Tasks blockiert sind) und bei Speicher und I/O eine „full“-Zeile (alle nicht untätigen Tasks gleichzeitig blockiert, was der Kernel als Thrashing beschreibt).
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io
PSI beantwortet direkt die Frage „Bremst diese Ressource die Arbeit aus?“ und ist damit ein gutes Alarmsignal. Existieren die Dateien nicht, wurde Ihr Kernel ohne PSI-Unterstützung gebaut oder gestartet.
Welche Tools eignen sich für dauerhaftes Monitoring?
Befehle zeigen, was gerade passiert. Um Probleme nachts abzufangen, Trends zu sehen und die richtige Person zu alarmieren, installieren Sie einen Monitoring-Agenten, der Metriken an einen Zeitreihenspeicher sendet.
| Tool | Geeignet für | Hinweise |
|---|---|---|
sysstat (sar) | Einzelne Server, Verlauf für die Fehlersuche | Zeichnet Metriken in festem Intervall in lokale Dateien auf; keine Alarmierung |
| Prometheus + node_exporter + Grafana | Viele Server, Kubernetes, Open-Source-Stack | node_exporter stellt Hardware- und Kernel-Metriken bereit; Alertmanager verschickt Alarme |
| Zabbix oder Nagios | Gemischte On-Premises-Umgebungen | Agentenbasiert, mit integrierten Vorlagen und Alarmierung |
| Amazon CloudWatch Agent | Linux auf AWS EC2 und Hybrid-Server | Der CloudWatch Agent ergänzt Metriken aus dem Gastsystem wie Speicher- und Datenträgernutzung, die das Basis-Monitoring von EC2 nicht zeigt |
| Azure Monitor Agent | Linux auf Azure und Arc-fähige Server | Sendet Gastmetriken und Syslog an Azure Monitor |
Welche Alarme sollten Sie zuerst einrichten?
- Speicherplatz und Inodes über 80–85 % auf einem beliebigen Dateisystem, mit einem Prognosealarm für „voll innerhalb von 24 Stunden“.
- Verfügbarer Speicher länger als 10 Minuten niedrig oder jedes OOM-Killer-Ereignis.
- Load Average länger als 15 Minuten über der Kernzahl oder steigende CPU-Pressure.
- Datenträgerlatenz oder I/O-Pressure deutlich über der normalen Baseline des Servers.
- Service-Checks: Der Anwendungsport antwortet und eine Health-URL liefert Erfolg.
- Backups und Zertifikatsablauf, die still scheitern.
Diese Schwellen sind Ausgangspunkte. Passen Sie sie an das normale Verhalten jedes Servers an, damit Alarme handlungsrelevant bleiben. Unser Leitfaden zur Überwachung der Serverleistung behandelt Windows und die allgemeine Praxis, und die Überwachung der Cloud-Infrastruktur die verwalteten Services jenseits des Servers.
Wie Opsio Ihnen hilft
Opsio überwacht und betreibt Linux-Server auf AWS, Azure und On-Premises als Teil unserer Managed IT Services, einschließlich 24/7-Alarmbearbeitung, Patching und Kapazitäts-Reviews, mit Prometheus und Grafana oder Cloud-nativen Werkzeugen. So läuft zum Beispiel die AWS-Plattform, die wir für WorkBuster gebaut haben, auf EC2-Instanzen in einer Auto-Scaling-Gruppe, mit CloudWatch-Dashboards und -Alarmen für den laufenden Betrieb.
Häufig gestellte Fragen
Was ist der beste Befehl, um die Leistung eines Linux-Servers zu prüfen?
Beginnen Sie mit top für einen Live-Überblick, dann vmstat 1 für CPU-, Speicher- und Swap-Trends und iostat -xz 1 für die Datenträger. Zusammen zeigen sie die meisten Engpässe innerhalb einer Minute.
Was ist eine gute Load Average für einen Linux-Server?
Das hängt von der Zahl der CPU-Kerne ab. Eine Load Average bis zur Kernzahl bedeutet meist, dass nichts in der Warteschlange steht. Dauerhafte Last über der Kernzahl heißt, dass Tasks auf CPU oder Datenträger warten.
Warum zeigt Linux fast keinen freien Speicher an?
Linux nutzt ungenutzten RAM als Disk-Cache und gibt ihn zurück, wenn Anwendungen ihn brauchen. Prüfen Sie stattdessen die Spalte available von free -h; das ist der Speicher, der tatsächlich für neue Arbeit zur Verfügung steht.
Wie sehe ich, welcher Prozess die meiste CPU oder den meisten Speicher nutzt?
Drücken Sie in top die Taste P, um nach CPU zu sortieren, und M, um nach Speicher zu sortieren. In einem Skript nutzen Sie ps aux --sort=-%cpu | head oder ps aux --sort=-%mem | head.
Wie überwache ich einen Linux-Server aus der Ferne?
Installieren Sie einen Agenten wie node_exporter, den Zabbix-Agenten oder den CloudWatch Agent und senden Sie die Metriken an einen zentralen Server oder Cloud-Service. So erhalten Sie Verlauf, Dashboards und Alarme, ohne sich auf jedem Rechner anzumelden.
Verfasst von

Country Manager, Schweden
Johan leitet die Schweden-Operationen von Opsio und treibt KI-Adoption, DevOps-Transformation, Sicherheitsstrategie und Cloud-Lösungen für nordische Unternehmen voran. Mit über 12 Jahren Erfahrung in der Cloud-Infrastruktur hat er mehr als 200 Projekte auf AWS, Azure und GCP geliefert — mit Schwerpunkt auf Well-Architected-Reviews, Landing-Zone-Design und Multi-Cloud-Strategie.
Redaktionelle Standards: Dieser Artikel wurde von der oben genannten Cloud-Fachperson verfasst. Wir überarbeiten ihn, wenn sich die behandelte Technologie oder Regulierung ändert; die Daten auf dieser Seite zeigen die letzte Aktualisierung. Opsio ist redaktionell unabhängig.