Ga naar de inhoud 
sar sysstat levert mij historische statistieken van Linux-servers, waarmee ik belastingpatronen, knelpunten en afwijkend gedrag nauwkeurig in de tijd kan volgen. Zo analyseer ik achteraf de CPU, het RAM, de I/O en het netwerk en herken ik terugkerende pieken die een puur live-tool gemakkelijk over het hoofd ziet.
Centrale punten
Ik vat de volgende kernpunten kort en duidelijk samen.
- Geschiedenis In plaats van een momentopname: door regelmatige registratie worden belastingspatronen zichtbaar.
- Combinatie uit verzameling en analyse: sysstat verzamelt, sar verwerkt.
- Breedte metingen: CPU, RAM, swap, schijf-I/O, netwerk en meer.
- Diagnose Oorzaken: tijdvensters gericht aanpassen en vergelijken.
- Planning met trends: capaciteiten realistisch bepalen.
Wat doen sar en sysstat in de dagelijkse praktijk?
Ik gebruik sar als System Activity Reporter, die de door sysstat opgeslagen gegevens leesbaar maakt. sysstat verzamelt regelmatig CPU-, geheugen-, I/O- en netwerkwaarden, terwijl ik met sar gericht rapporten voor bepaalde tijdsperioden opvraag. Zo kan ik terugkerende piekperiodes als gevolg van back-ups, cronjobs of verkeerspieken herkennen zonder te hoeven gissen. In tegenstelling tot Live-tools Net als bij `top` of `htop` beoordeel ik niet de momentane toestand, maar houd ik rekening met de ontwikkeling in de tijd. Dit perspectief voorkomt verkeerde diagnoses, omdat het oorzaak en gevolg van elkaar scheidt en mij betrouwbare aanwijzingen geeft.
Installatie en activering op gangbare distributies
Ik installeer sysstat Activeer via de pakketbeheerder de registratie en controleer de systemd-timers. Onder Debian/Ubuntu volstaat meestal apt install sysstat en een blik in /etc/default/sysstatgevolgd door systemctl enable --now sysstat. Op RHEL/CentOS/Oracle Linux gebruik ik dnf install sysstat en stel de timers in via systemctl. Daarna worden de dagbestanden doorgaans opgeslagen in /var/log/sa/ met namen als sa10 voor de 10e van de maand. Ik controleer de registratie met sar zonder parameters of met sar -u 1 3 voor een korte ad-hoccontrole.
Uitleg over de belangrijkste SAR-oproepen
Voor de CPU gebruik ik sar -u en indien nodig per kern sar -u -P ALLom Tips niet te missen. Ik beschouw opslag en caching als sar -r en swapping met sar -S. De activiteit van de platen lees ik af met sar -d, het netwerk met sar -n DEV,ETCP,TCP,UDP. Historische bestanden open ik met sar -f /var/log/sa/sa10 en beperk het tijdvenster met -s UU:MM -e UU:MM een. Voor gedetailleerde analyses van wachttijden voeg ik sar toe door I/O-wachttijden analyseren, omdat ik zo wachtrijen en doorvoer beter kan beoordelen en Knelpunten duidelijk identificeer.
Meetwaarden correct aflezen: CPU, geheugen, I/O, netwerk
Ik kijk naar een paar kengetallen die me snel een betrouwbaar beeld geven en die ik in de loop van de tijd met elkaar vergelijk. CPU-Inactief Waarden dicht bij 0 en een hoge %iowait duiden op wachtrijen bij de schijf. Een hoge %steal duidt op CPU-tekort bij virtualisatie. Wat het RAM betreft, let ik op vrije geheugenpagina's, het gedrag van de paginacache en swap-ins/outs. Voor het netwerk helpen pakketfouten, drops en retransmissies om capaciteitsbeperkingen of storingen te herkennen.
| Metriek | sar-schakelaar | Opvallende waarden | onmiddellijke maatregel |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle zeer laag, %iowait hoog | I/O controleren, threads verdelen, CPU-behoefte valideren |
| Geheugen | sar -r | weinig vrije ruimte, sterk verlies van paginacache | Diensten optimaliseren, RAM uitbreiden, caching evalueren |
| Wissel | sar -S | veelvoorkomende swap-ins/outs | Het werkgeheugen ontlasten, limieten aanpassen |
| Schijf-I/O | sar -d | hoge await-/svctm-waarden, wachtrij groeit | I/O-profiel controleren, storage-tiering of batchvenster aanpassen |
| Netwerk | sar -n DEV,ETCP | Drops, fouten, heruitzendingen | MTU/offloading testen, bandbreedte en latentie analyseren |
Historische gegevens en tijdsperioden analyseren
Ik werk bijna altijd met Tijdvensters, bijvoorbeeld sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 voor nachtelijke klussen. Zo vergelijk ik dezelfde tijdstippen op verschillende dagen en zie ik trends in plaats van losse gevallen. Voor automatische analyse sla ik gegevens op met sadf -d in CSV-formaat en laad ik ze in een eigen dashboard. Bij ongebruikelijke pieken bekijk ik de aangrenzende intervallen om neveneffecten uit te sluiten. Ik houd deze methode eenvoudig, omdat ze me snel bruikbare aanwijzingen oplevert zonder dat er veel voorbereidend werk nodig is.
Trendanalyse en capaciteitsplanning
Ik gebruik de gearchiveerde waarden voor Prognoses en bepaal de benodigde resources op basis van concrete gegevens in plaats van op basis van een onderbuikgevoel. Als de CPU-belasting week na week toeneemt, plan ik extra cores of klokreserves in. Als de behoefte aan werkgeheugen door caches toeneemt, weeg ik de voordelen af tegen een RAM-uitbreiding. Als het I/O-pad langere wachttijden vertoont, kies ik voor snellere opslag of ontkoppelde batchvensters. Voor visualisatie koppel ik gegevens als alternatief aan Grafana en Prometheus en combineer SAR-trends met statistieken uit exportgegevens.
Praktijkvoorbeeld: webserver met piekbelastingen
Ik schets een situatie waarin WordPress-pagina’s elke avond traag reageren en Gebruikers Meldingen van afbrekingen. Met sar -u -s 18:00:00 -e 20:00:00 en sar -d Ik merk gelijktijdige I/O-pieken tijdens back-ups. Tegelijkertijd laat sar -n DEV een stijgende netwerkdoorvoer, wat het beeld van de belasting compleet maakt. De controleproef de volgende dag, zonder back-up, bevestigt dit patroon. Ik verplaats de taak, optimaliseer de databasequery’s en pas de caches aan, waardoor de pieken in de avond verdwijnen en de responstijden weer constant blijven.
Tips voor gegevensbeheer, rotatie en bewaring
Ik controleer de Opslag in /etc/sysconfig/sysstat of /etc/default/sysstat en stel de bewaartermijn in naar behoefte. Voor kritieke hosts bewaar ik gegevens 30–90 dagen om seizoensgebonden effecten te kunnen herkennen. De bestandsgrootte blijft beheersbaar, zolang de intervallen zinvol zijn en er geen buitensporige secondenintervallen worden gebruikt. Ik verplaats oudere archieven naar een centrale map of voeg ze toe aan een eenvoudige langetermijnopslag. Zo houd ik gegevens beschikbaar zonder het systeem te belasten of de analyse te vertragen.
Integratie met monitoringstacks en logbestanden
Ik stel sar gelijk aan Ruwe gegevens-leverancier en combineer dit met centrale monitoring, logboekanalyse en alarmering. Een APM- of logboekstack levert mij gebeurtenissen, terwijl sar de infrastructuurwaarden in de tijd indeelt. Voor bijzonder luidruchtige hosts gebruik ik bovendien pidstat en iostat, om processen en I/O-paden aan elkaar te koppelen. Daarnaast helpt het mij Procesboekhouding, om processen die veel resources verbruiken duidelijk in kaart te brengen. Deze combinatie van gebeurtenis- en metriekweergave voorkomt dat ik op goed geluk te werk ga en verkort mijn foutopsporing aanzienlijk.
De configuratie nauwkeurig afstemmen: intervallen, sa1/sa2 en timer
Ik heb de Registratie-intervallen zo instellen dat ze aansluiten bij de dynamiek van het systeem. Een interval van één minuut is een geschikte standaard, terwijl bij zeer volatiele hosts ook een interval van 10–30 seconden zinvol kan zijn. De verzameling neemt het over sa1 (regelmatige steekproeven), het dagoverzicht sa2 (Verslagen van de dag). Onder systemd controleer ik de betreffende timers of services en pas ik de frequentie aan. Op Debian/Ubuntu activeer ik het verzamelen vaak expliciet met ENABLED="true" in /etc/default/sysstat. Ik leg de intervallen per omgeving vast, zodat latere vergelijkingen correct zijn en niemand op basis van steekproeven van 5 seconden verkeerde conclusies trekt ten opzichte van gegevens van 1 minuut.
Overzicht van geavanceerde sar-opties
Naast de standaardknoppen helpen extra schakelaars mij bij het Volledig overzicht: sar -b geeft de geaggregeerde Block-I/O-doorvoer weer, sar -B het paginggedrag van de kernel en sar -W de swap-activiteit in detail. Met sar -q Ik zie de runqueue (processen die wachten op de CPU) en de ontwikkeling van de belasting. sar -H levert Hugepage-gegevens, indien van toepassing. Voor platen gebruik ik indien nodig sar -d -p, om partities afzonderlijk te bekijken. Ik ben voorzichtig met svctm: Deze waarde is in moderne kernels soms onbetrouwbaar of gelijk aan 0; ik geef er de voorkeur aan om wacht op (end-to-end-latentie) en avgqu-sz/aqu-sz (wachtrijgrootte). En als ik snel een algemeen beeld wil krijgen, geeft sar -A een breed overzicht, dat ik daarna verder uitdiep.
Virtuele machines en containers correct beoordelen
Op Virtualisaties Ik let vooral op %steal: hoge Steal-waarden betekenen dat de hypervisor CPU-tijd aan de VM onttrekt. Dat leidt gemakkelijk tot verkeerde inschattingen als ik alleen naar %idle kijk. Daarom breng ik CPU-belasting, Steal en Runqueue in verband met elkaar (sar -q) samen. In containeromgevingen maak ik een onderscheid tussen de host en de workload: sar houdt de host in de gaten, niet de afzonderlijke containers. Als ik details per dienst nodig heb, vul ik dat aan met pidstat (per proces) en houd rekening met cgroups-limieten. Ik controleer bovendien de schaalbaarheid van de CPU-frequentie en de energietoestanden (kloksnelheidswijzigingen), omdat deze op korte termijn vertragingen kunnen veroorzaken die, zonder context, lijken op een tekort aan CPU-capaciteit.
Tijdsreferentie: tijdzones, zomertijd en betrouwbare correlatie
Ik let op constante tijdbasis, zodat vergelijkingen kloppen. sar slaat standaard op in lokale tijd; bij clusters is het raadzaam om een uniforme tijdzone te gebruiken (vaak UTC). Rond de zomertijdwisseling controleer ik op dubbele of ontbrekende tijdvakken en maak ik indien nodig gebruik van de uitvoer van sadf met tijdstempels in ISO-formaat. Voor correlaties met logbestanden of APM-gebeurtenissen stem ik de tijdzones op elkaar af, om pieken in statistieken exact te koppelen aan gebeurtenissen (implementaties, back-ups, cronjobs). Duidelijke tijdreferenties verminderen misverstanden bij incident-postmortems aanzienlijk.
Automatiseren en exporteren met sadf
Voor rapporten en dashboards exporteer ik gegevens met sadf. In het dagelijks leven gebruik ik sadf -d (CSV) voor eenvoudige analyses, of als alternatief sadf -j (JSON) voor flexibele pijplijnen. Een typische export ziet er als volgt uit: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_avond.csv. Zo genereer ik een bestand met CPU-, RAM-, blok-I/O- en netwerkstatistieken voor een avondperiode. In scripts vergelijk ik hiermee automatisch weekdagen, bereken ik de mediaan en het 95e percentiel en markeer ik uitschieters. Ik houd het aantal statistieken bewust beperkt om de leesbaarheid te behouden en valse alarmen te voorkomen.
Praktijkvoorbeeld: databaseserver met paginacache-belasting
Een MySQL-host klaagt over sporadische vertragingen bij query's. sar -r laat ’s avonds een afnemende paginacache zien, sar -S incidentele swap-outs. Tegelijkertijd neemt bij sar -d de wacht op-tijd, en sar -b wijst op verhoogde schrijfstromen. De correlatie met logrotaties en een ETL-taak verklaart het patroon: grote sequentiële schrijfgolven verdringen de cache en duwen leesbewerkingen van de database naar I/O. Ik spreid de taken, verhoog het RAM-geheugen gematigd en stel de DB-buffer doelgericht groter in. Daarna blijven de ‘await’- en ‘swap’-waarden stabiel, dalen de latenties en houdt de paginacache de hotsets betrouwbaar in het geheugen.
Bedrijfsaspecten: overhead, apparatuurlijsten en filters
Ik houd de Overhead klein, door steekproeven op een evenwichtige manier te selecteren. Sysstat leest voornamelijk uit /proc en schrijft binair; bij intervallen van enkele minuten merk ik de belasting nauwelijks. Op hosts met zeer veel apparaten of kortstondige blokapparaten (bijvoorbeeld bij snapshots) filter ik de uitvoer doelgericht en evalueer ik alleen relevante paden. Voor dm-crypt, MD-RAID of multipath-apparaten controleer ik zowel het logische als – waar mogelijk – het onderliggende apparaat om knelpunten correct toe te wijzen. Daarbij documenteer ik de apparaatnamen, zodat latere vergelijkingen niet mislukken door hernoemde paden.
Methodologie: referentiewaarden en vergelijkingsdagen
Ik definieer per host een Basislijn per dagelijkse tijdsperiode (bijv. 01–05 uur batch, 09–18 uur kantoor, 18–22 uur piek). Voor elke periode noteer ik de typische mediaanwaarden en aanvaardbare percentielen (bijv. CPU-%idle, wacht op, avgqu-sz, heruitzendingen). Bij afwijkingen ga ik eerst op zoek naar nieuwe opdrachten, implementaties of verkeerspatronen – pas daarna denk ik aan capaciteitsuitbreidingen. Deze gedisciplineerde volgorde voorkomt overhaaste beslissingen: vaak lost een kleine wijziging in de planning of een aanpassing van de limiet meer op dan dure hardware-uitbreidingen. sar levert mij daarvoor de betrouwbare feitelijke basis over weken en maanden heen.
Grenzen en nuttige toevoegingen
Ik zie sar niet als vervanging voor Waarschuwing, omdat het standaard geen drempelwaarden bewaakt of meldingen verstuurt. Real-time waarschuwingen horen thuis in speciale systemen die regels, escalaties en teamworkflows in kaart brengen. Ook diepgaande statistieken over applicaties, databases of JVM’s behandel ik via exporteurs en tracing. sar blinkt uit wanneer ik systeembronnen historisch wil vergelijken en knelpunten in de bedrijfsvoering wil achterhalen. Kortom, ik zet het doelgericht in wanneer snelle, herhaalbare antwoorden op infrastructurele vragen nodig zijn.
Kort samengevat
Ik gebruik sar en sysstat, om van meetwaarden een duidelijk beeld van de serverbelasting te krijgen. De combinatie van regelmatige gegevensverzameling en gerichte terugblik brengt de oorzaken aan het licht, in plaats van alleen maar naar symptomen te gissen. Met slechts enkele commando’s spoor ik CPU-, geheugen-, I/O- en netwerkproblemen op en leg ik vast wanneer ze zich voordoen. Hieruit leid ik realistische beslissingen over de capaciteit af en herken ik inefficiënte routines, zoals back-ups op een slecht getimed moment. Wie verantwoordelijk is voor Linux-servers, krijgt met deze methode betrouwbare houvast en bespaart tijd bij analyse, planning en beheer.
