Linux-serverprestaties monitoren: commando's, metrics en tools

Om de prestaties van een Linux-server te monitoren, controleert u vier resources: CPU, geheugen, schijf-I/O en netwerk. Gebruik ingebouwde commando's zoals top, vmstat, free, iostat en ss voor live troubleshooting, en een agent-gebaseerde tool zoals Prometheus met node_exporter, Zabbix of de CloudWatch-agent om historie op te slaan en alerts te versturen.

Belangrijkste punten

• Controleer per resource het gebruik, de verzadiging en de fouten (de USE-methode). Een hoog gebruik alleen is geen probleem; wachtrijen en fouten wel.
• Vergelijk de load average met het aantal CPU-cores, en let op %wa (I/O-wachttijd) en %st (steal time) bij cloud-VM's.
• Lees bij geheugen de kolom available van free, niet free. Linux gebruikt vrij geheugen bewust als cache.
• Pressure stall information in /proc/pressure/ laat direct zien hoeveel tijd taken wachten op CPU, geheugen of I/O.
• Commando's tonen het heden. Voor trends en alerts hebt u een monitoringagent en een time-series-opslag nodig.

Welke Linux-prestatiemetrics tellen?

Begin met de USE-methode van performance-engineer Brendan Gregg: controleer voor elke resource het gebruik (utilisation), de verzadiging (saturation) en de fouten (errors). Het geeft u een checklist in plaats van gokwerk.

Hoe controleert u CPU-gebruik en load op Linux?

Start top (of htop) en lees de CPU-regel, en vergelijk daarna de load average met het aantal cores uit nproc.

top # live weergave; druk op 1 om elke core te tonen
nproc # aantal CPU-cores
uptime # load average over 1, 5 en 15 minuten
mpstat -P ALL 1 # gebruik per core, elke seconde (pakket sysstat)

Volgens de man-pagina van proc_loadavg telt de load average taken die draaien of wachten op schijf-I/O, gemiddeld over 1, 5 en 15 minuten. Een load van 6 op een server met 8 cores is prima. Een load van 6 op een server met 2 cores betekent dat er werk in de wachtrij staat. Omdat de load ook processen meetelt die op de schijf wachten, wijst een hoge load bij laag CPU-gebruik meestal op een opslagprobleem.

In de CPU-regel van top zijn op cloudservers twee velden belangrijk:

• wa: tijd dat de CPU stilstond in afwachting van I/O. Aanhoudend hoge waarden wijzen op trage schijven of netwerkopslag.
• st: volgens de man-pagina van top "time stolen from this vm by the hypervisor", dus tijd die de hypervisor van deze VM afnam. Aanhoudende steal op een cloud-VM betekent dat de host druk is of dat een burstable instance zijn CPU-credits heeft opgebruikt.

Hoe controleert u het geheugengebruik op Linux?

Start free -h en lees de kolom available. De man-pagina van free definieert die als een schatting van het geheugen dat beschikbaar is voor nieuwe applicaties zonder te swappen, rekening houdend met de page cache.

free -h # geheugenoverzicht in leesbare eenheden
vmstat 1 5 # de kolommen si/so tonen swap in/uit per seconde
journalctl -k | grep -i "out of memory" # gebeurtenissen van de OOM-killer

Een server met weinig "free" maar veel "available" geheugen is gezond: Linux vult ongebruikt RAM met schijfcache en geeft die vrij zodra programma's het nodig hebben. Waarschuwingssignalen zijn een dalend available-geheugen over meerdere dagen (mogelijk een geheugenlek), voortdurende swapactiviteit in vmstat en meldingen van de OOM-killer in het kernellog.

Hoe controleert u schijfprestaties en -ruimte?

Gebruik iostat -xz 1 voor I/O-prestaties en df voor ruimte en inodes.

iostat -xz 1 # gebruik, wachtrij en latentie per apparaat (sysstat)
df -h # schijfruimte per bestandssysteem
df -i # inodegebruik: veel kleine bestanden kunnen deze als eerste vullen
du -sh /var/log/* | sort -h # zoek uit wat ruimte gebruikt

Let in iostat op r_await en w_await (gemiddelde milliseconden per request) en aqu-sz (wachtrijlengte). De man-pagina van iostat merkt op dat %util bij apparaten die requests parallel afhandelen, zoals RAID-arrays en moderne SSD's, niet hun prestatiegrenzen weergeeft. Stijgende latentie en wachtrijlengte zijn betere tekenen van verzadiging.

Hoe monitort u netwerkprestaties?

sar -n DEV 1 # doorvoer per interface
sar -n TCP,ETCP 1 # TCP-verbindingen en retransmits
ss -s # samenvatting van sockets
ip -s link # fouten en verloren pakketten per interface

Stijgende retransmits, verloren pakketten of interfacefouten wijzen op netwerkproblemen, ook als de doorvoer normaal lijkt. Vergelijk op cloud-VM's de doorvoer met de netwerklimiet van het instancetype.

Wat is pressure stall information (PSI)?

PSI is een kernelfunctie die rapporteert hoeveel tijd taken wachten op CPU, geheugen of I/O. De kerneldocumentatie legt uit dat elk bestand in /proc/pressure/ een "some"-regel heeft (het deel van de tijd dat ten minste enkele taken stilstaan) en, voor geheugen en I/O, een "full"-regel (alle niet-inactieve taken staan tegelijk stil, wat de kernel beschrijft als thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

PSI beantwoordt direct de vraag "vertraagt deze resource het werk?", wat het een goed alertsignaal maakt. Bestaan de bestanden niet, dan is uw kernel zonder PSI-ondersteuning gebouwd of gestart.

Welke tools gebruikt u voor continue monitoring?

Commando's tonen wat er nu gebeurt. Om problemen 's nachts te vangen, trends te zien en de juiste persoon te waarschuwen, installeert u een monitoringagent die metrics naar een time-series-opslag stuurt.

Welke alerts stelt u eerst in?

1. Schijfruimte en inodes boven 80–85% op elk bestandssysteem, met een voorspellingsalert voor "vol binnen 24 uur".
2. Beschikbaar geheugen langer dan 10 minuten laag, of elke gebeurtenis van de OOM-killer.
3. Load average langer dan 15 minuten boven het aantal cores, of stijgende CPU-pressure.
4. Schijflatentie of I/O-pressure ruim boven de normale basislijn van de server.
5. Servicechecks: de applicatiepoort reageert en een health-URL geeft succes terug.
6. Back-ups en het verlopen van certificaten, die ongemerkt mislukken.

Deze drempels zijn uitgangspunten. Stem ze af op het normale gedrag van elke server, zodat alerts bruikbaar blijven. Onze gids over serverprestaties monitoren behandelt Windows en algemene praktijk, en cloudinfrastructuur monitoren behandelt managed services voorbij de server.

Hoe Opsio helpt

Opsio monitort en beheert Linux-servers op AWS, Azure en on-premises als onderdeel van onze managed IT-services, inclusief 24/7 alertafhandeling, patching en capaciteitsreviews, met Prometheus en Grafana of cloud-native tooling. Zo draait het AWS-platform dat we voor WorkBuster bouwden op EC2-instances in een auto-scaling group, met CloudWatch-dashboards en -alarmen voor het dagelijkse beheer.

Veelgestelde vragen

Wat is het beste commando om Linux-serverprestaties te controleren?

Begin met top voor een live overzicht, daarna vmstat 1 voor trends in CPU, geheugen en swap, en iostat -xz 1 voor schijven. Samen laten ze binnen een minuut de meeste knelpunten zien.

Wat is een goede load average voor een Linux-server?

Dat hangt af van het aantal CPU-cores. Een load average op of onder het aantal cores betekent meestal dat er geen wachtrij is. Aanhoudende load boven het aantal cores betekent dat taken wachten op CPU of schijf.

Waarom toont Linux bijna geen vrij geheugen?

Linux gebruikt ongebruikt RAM als schijfcache en geeft het terug wanneer applicaties het nodig hebben. Controleer in plaats daarvan de kolom available van free -h; dat is het geheugen dat echt beschikbaar is voor nieuw werk.

Hoe zie ik welk proces de meeste CPU of het meeste geheugen gebruikt?

Druk in top op P om op CPU te sorteren en op M om op geheugen te sorteren. Gebruik vanuit een script ps aux --sort=-%cpu | head of ps aux --sort=-%mem | head.

Hoe monitor ik een Linux-server op afstand?

Installeer een agent zoals node_exporter, de Zabbix-agent of de CloudWatch-agent, en stuur metrics naar een centrale server of cloudservice. Dan hebt u historie, dashboards en alerts zonder op elke machine in te loggen.