Videre til indhold 
sar sysstat giver mig historiske målinger fra Linux-servere, som jeg kan bruge til nøje at følge belastningsmønstre, flaskehalse og afvigende adfærd over tid. På den måde kan jeg analysere CPU, RAM, I/O og netværk i tilbageblik og opdage tilbagevendende spidsbelastninger, som et rent live-værktøj let kan overse.
Centrale punkter
Jeg vil kort og klart sammenfatte følgende hovedbudskaber.
- Historie I stedet for et øjebliksbillede: Regelmæssig registrering afslører belastningsmønstre.
- Kombination fra indsamling og analyse: sysstat indsamler, sar behandler.
- Bredde Målinger: CPU, RAM, swap, disk-I/O, netværk og mere.
- Diagnose Af årsager: Juster tidsvinduerne målrettet og sammenlign dem.
- Planlægning med Trends: Dimensionering af kapaciteter på et realistisk grundlag.
Hvad kan sar og sysstat bruges til i hverdagen?
Jeg bruger sar som System Activity Reporter, der gør de data, som sysstat gemmer, læselige. sysstat indsamler regelmæssigt CPU-, hukommelses-, I/O- og netværksværdier, mens jeg med sar målrettet henter rapporter for bestemte tidsperioder. På den måde kan jeg uden gætterier identificere tilbagevendende belastningsperioder som følge af sikkerhedskopieringer, cron-jobs eller trafikspidser. I modsætning til Live-værktøjer Ligesom med top eller htop vurderer jeg ikke den øjeblikkelige tilstand, men tager udviklingen over tid med i betragtning. Dette perspektiv forhindrer fejldiagnoser, fordi det adskiller årsag og virkning og giver mig pålidelige indikationer.
Installation og aktivering på almindelige distributioner
Jeg installerer sysstat Via pakkehåndteringen skal du aktivere logningen og kontrollere systemd-timerne. Under Debian/Ubuntu er det som regel nok at apt install sysstat og et kig ind i /etc/default/sysstatefterfulgt af systemctl enable --now sysstat. På RHEL/CentOS/Oracle Linux bruger jeg dnf install sysstat og styr timerne via systemctl. Derefter gemmes dagsfilerne normalt under /var/log/sa/ med navne som sa10 den 10. i måneden. Jeg bekræfter registreringen med sar uden parametre eller med sar -u 1 3 til en hurtig ad hoc-kontrol.
De vigtigste sar-kommandoer forklaret
Til CPU bruger jeg sar -u og om nødvendigt pr. kerne sar -u -P ALLtil Tips man kan ikke overse det. Jeg betragter lagring og caching som sar -r og swapping med sar -S. Jeg aflæser pladeaktiviteten med sar -d, netværket med sar -n DEV,ETCP,TCP,UDP. Historiske filer åbner jeg med sar -f /var/log/sa/sa10 og afgrænse tidsvinduer med -s TT:MM -e TT:MM . For detaljerede analyser af ventetider tilføjer jeg sar ved hjælp af Analyse af I/O-ventetider, fordi jeg på den måde bedre kan vurdere køer og gennemstrømning, og Flaskehalse identificer klart.
Sådan aflæses måleværdier korrekt: CPU, hukommelse, I/O, netværk
Jeg ser på nogle få nøgletal, som hurtigt giver mig et pålideligt overblik, og som jeg sammenligner over tid. CPU-Inaktiv Værdier tæt på 0 og høje %iowait-værdier tyder på køer ved harddisken. En høj %steal afslører CPU-mangel i virtualiseringen. Hvad angår RAM, holder jeg øje med ledige hukommelsessider, pagecache-adfærd og swap-ins/outs. For netværket hjælper pakkefejl, drops og retransmissions med at identificere kapacitetsgrænser eller forstyrrelser.
| Metrikker | sar-kontakt | Usædvanlige værdier | øjeblikkelig foranstaltning |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle meget lav, %iowait høj | Kontroller I/O, fordel tråde, valider CPU-behov |
| Hukommelse | sar -r | lidt ledig plads, stort tab af sidecache | Optimere tjenester, udvide RAM, evaluere caching |
| Bytte | sar -S | hyppige udskiftninger | Aflaste arbejdshukommelsen, justere grænserne |
| Disk-I/O | sar -d | Høje await-/svctm-værdier, køen vokser | Kontroller I/O-profilen, juster lagringslagdeling eller batch-vinduer |
| Netværk | sar -n DEV,ETCP | Drops, fejl, genudsendelser | Test af MTU/offloading, analyse af båndbredde og latenstid |
Analyse af historiske data og tidsvinduer
Jeg arbejder næsten altid med Tidsvinduer, for eksempel sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 til natlige opgaver. På den måde sammenligner jeg identiske tidspunkter på forskellige dage og kan se tendenser i stedet for enkeltstående tilfælde. Til maskinel analyse gemmer jeg data med sadf -d i CSV-format og importerer dem til mit eget dashboard. Ved usædvanlige spidsbelastninger ser jeg på de tilstødende intervaller for at udelukke bivirkninger. Jeg holder denne metode enkel, fordi den giver mig hurtigt anvendelige oplysninger uden lang forberedelse.
Trendanalyse og kapacitetsplanlægning
Jeg bruger de arkiverede værdier til Prognoser og dimensionerer ressourcerne ud fra reelle mønstre i stedet for mavefornemmelse. Hvis CPU-udnyttelsen stiger fra uge til uge, planlægger jeg at tilføje kerner eller klokfrekvensreserver. Hvis behovet for arbejdshukommelse stiger på grund af cacher, afvejer jeg fordelene ved en RAM-udvidelse. Hvis I/O-stien viser øgede ventetider, beslutter jeg mig for hurtigere lagring eller adskilte batch-vinduer. Til visualisering integrerer jeg alternativt data i Grafana og Prometheus og kombiner SAR-trends med målinger fra eksportører.
Praksiseksempel: Webserver med spidsbelastninger
Jeg vil skitsere et tilfælde, hvor WordPress-sider hver aften reagerer med forsinkelse, og Brugere Indberet afbrud. Med sar -u -s 18:00:00 -e 20:00:00 og sar -d Jeg oplever samtidige I/O-spidsbelastninger under sikkerhedskopieringer. Samtidig viser sar -n DEV stigende netværksgennemstrømning, hvilket fuldender belastningsbilledet. En kontrolmåling dagen efter uden backup bekræfter mønsteret. Jeg flytter jobbet, optimerer databaseforespørgslerne og renser cacherne, hvorved aftenens spidsbelastninger forsvinder, og svartiderne igen forbliver konstante.
Tips til datahåndtering, rotation og opbevaring
Jeg tjekker Opbevaring på /etc/sysconfig/sysstat eller /etc/default/sysstat og indstiller opbevaringsperioden efter behov. For kritiske værter gemmer jeg data i 30–90 dage for at kunne identificere sæsonmæssige effekter. Filstørrelsen forbliver overskuelig, så længe intervallerne er fornuftige, og der ikke er aktiveret en overdreven sekundbaseret opdateringsfrekvens. Jeg flytter ældre arkiver til et centralt bibliotek eller overfører dem til et simpelt langtidsarkiv. På den måde holder jeg dataene tilgængelige uden at belaste systemet eller gøre analysen langsommere.
Integration med overvågningsstakke og logfiler
Jeg sætter sar som Rå data-leverandør og kombinerer det med central overvågning, loganalyse og alarmering. En APM- eller log-stack leverer hændelser til mig, mens sar tidsordner infrastrukturværdierne. For særligt støjende værter bruger jeg desuden pidstat og iostat, for at tilordne processer og I/O-stier. Derudover hjælper det mig Procesregnskab, at identificere ressourcekrævende processer præcist. Denne kombination af hændelses- og metrikvisning forhindrer, at jeg går i blinde, og forkorter min fejlsøgning betydeligt.
Finjustering af konfigurationen: Intervaller, sa1/sa2 og timer
Jeg satte Registreringsintervaller indstilles, så de passer til systemets dynamik. Et minutinterval er et oplagt standardvalg, mens intervaller på 10–30 sekunder også kan være hensigtsmæssige for meget volatile værter. Indsamlingen foretages sa1 (hyppige stikprøver), dagens oversigt sa2 (Daglige rapporter). I systemd tjekker jeg de relevante timere eller tjenester og justerer hyppigheden. På Debian/Ubuntu aktiverer jeg ofte indsamlingen eksplicit med ENABLED="true" på /etc/default/sysstat. Jeg dokumenterer intervallerne for hvert miljø, så senere sammenligninger bliver korrekte, og ingen drager forkerte konklusioner ud fra 5-sekunders stikprøver i forhold til 1-minuts data.
Oversigt over avancerede sar-indstillinger
Ud over de klassiske funktioner hjælper ekstra kontakter mig med at Fuld oversigt: sar -b viser den samlede Block-I/O-throughput, sar -B kernens paging-adfærd og sar -W Swap-aktiviteten i detaljer. Med sar -q Jeg kan se Runqueue (processer, der venter på CPU) og udviklingen i belastningen. sar -H leverer Hugepage-data, hvis det er relevant. Til plader bruger jeg om nødvendigt sar -d -p, for at kunne se partitionerne hver for sig. Jeg er forsigtig med svctm: Denne værdi er i moderne kerner til tider upålidelig eller lig med 0; jeg foretrækker at vurdere afvente (end-to-end-latens) og avgqu-sz/aqu-sz (køens størrelse). Og når jeg har brug for et hurtigt overblik, giver sar -A et bredt overblik, som jeg derefter indsnævrer.
Sådan vurderes virtuelle maskiner og containere korrekt
På Virtualiseringer Jeg lægger især mærke til %steal: Høje Steal-værdier betyder, at hypervisoren trækker CPU-tid fra VM’en. Det kan let føre til fejlvurderinger, hvis jeg kun vurderer %idle. Derfor sammenholder jeg CPU-udnyttelse, Steal og Runqueue (sar -q) sammen. I containermiljøer adskiller jeg værts- og arbejdsbelastningsperspektivet: sar overvåger værten, ikke de enkelte containere. Hvis jeg har brug for detaljer pr. tjeneste, supplerer jeg med pidstat (pr. proces) og tager højde for cgroups-grænser. Jeg tjekker desuden CPU-frekvensskalering og strømtilstande (frekvensskift), da disse på kort sigt kan forårsage forsinkelser, der uden sammenhæng kan virke som CPU-mangel.
Tidsreference: tidszoner, sommertid og pålidelig sammenhæng
Jeg er opmærksom på konstant tidsbasis, så sammenligningerne stemmer. sar gemmer som standard i lokal tid; i klynger er det en fordel at bruge en ensartet tidszone (ofte UTC). I forbindelse med sommertidsskiftet tjekker jeg for dobbelte eller manglende tidsvinduer og bruger om nødvendigt udskriften fra sadf med tidsstempler i ISO-format. Til sammenkobling med logfiler eller APM-hændelser justerer jeg tidszoner for nøjagtigt at kunne sammenholde spidsbelastninger i målinger med hændelser (implementeringer, sikkerhedskopieringer, cron-jobs). Klare tidsreferencer reducerer misforståelser i postmortem-analyser af hændelser betydeligt.
Automatisering og eksport med sadf
Til rapporter og dashboards eksporterer jeg data med sadf. I hverdagen bruger jeg sadf -d (CSV) til enkle analyser, alternativt sadf -j (JSON) til fleksible pipelines. En typisk eksport ser således ud: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. På den måde genererer jeg en fil med CPU-, RAM-, blok-I/O- og netværksnøgletal for et aftenvindue. I scripts sammenligner jeg automatisk ugedage med disse tal, beregner medianen og 95. percentilen og markerer afvigelser. Jeg holder bevidst antallet af målepunkter lavt for at bevare læsbarheden og undgå falske alarmer.
Praktisk eksempel: Databaseserver med belastning fra sidecache
En MySQL-host klager over sporadiske forsinkelser i forespørgslerne. sar -r viser et fald i sidecachen om aftenen, sar -S lejlighedsvise swap-outs. Samtidig vokser hos sar -d som afvente-tid, og sar -b tyder på øgede skrivebelastninger. Sammenhængen med log-rotationer og et ETL-job forklarer mønsteret: Store sekventielle skrivebølger fortrænger cachen og skubber læsninger fra databasen ud i I/O. Jeg spreder jobbene, øger RAM-kapaciteten moderat og indstiller DB-bufferen målrettet til en større størrelse. Herefter forbliver »await«- og »swap«-værdierne stabile, latenstiderne falder, og pagecachen holder hotsets pålideligt i hukommelsen.
Driftsmæssige aspekter: Overhead, udstyrslister og filtre
Jeg holder Overhead lille ved at udvælge stikprøverne forholdsmæssigt. Sysstat læser primært fra /proc og skriver binært; ved minutintervaller mærker jeg næsten ikke belastningen. På værter med meget mange enheder eller kortvarige blokenheder (f.eks. ved snapshots) filtrerer jeg udskriften målrettet og vurderer kun relevante stier. For dm-crypt, MD-RAID eller multipath-enheder tjekker jeg både den logiske enhed og – hvor det er muligt – den underliggende enhed for korrekt at kunne identificere flaskehalse. Jeg dokumenterer i den forbindelse enhedsnavnene, så senere sammenligninger ikke mislykkes på grund af omdøbte stier.
Metodik: Baseline-værdier og sammenligningsdage
Jeg definerer én pr. vært Baseline pr. tidsvindue (f.eks. kl. 01–05: Batch, kl. 09–18: Office, kl. 18–22: Peak). For hvert tidsvindue noterer jeg mig typiske medianværdier og acceptable percentiler (f.eks. CPU-%idle, afvente, avgqu-sz, retransmissioner). Hvis der er afvigelser, ser jeg først efter nye opgaver, implementeringer eller trafikmønstre – først derefter overvejer jeg kapacitetsudvidelser. Denne disciplinerede rækkefølge forhindrer forhastede beslutninger: Ofte løser en lille ændring i planen eller en justering af grænserne problemet bedre end en dyr udvidelse af hardware. sar leverer mig det pålidelige faktagrundlag herfor over uger og måneder.
Grænser og nyttige tilføjelser
Jeg ser ikke sar som en erstatning for Advarsel, fordi det som standard hverken overvåger tærskelværdier eller sender notifikationer. Realtidsadvarsler hører hjemme i dedikerede systemer, der håndterer regler, eskaleringer og team-workflows. Også dybtgående målinger vedrørende applikationer, databaser eller JVM’er dækker jeg via eksportværktøjer og sporing. sar udmærker sig, når jeg vil sammenligne systemressourcer historisk og spore flaskehalse i driften. Alt i alt bruger jeg det målrettet, hvor der er brug for hurtige, gentagelige svar på infrastrukturspørgsmål.
Kort opsummeret
Jeg bruger sar og sysstat for at skabe et overskueligt billede af serverbelastningen ud fra måleværdier. Kombinationen af regelmæssig dataindsamling og målrettet tilbageblik afklarer årsagerne i stedet for at gætte på symptomerne. Med få kommandoer afdækker jeg problemer med CPU, hukommelse, I/O og netværk og dokumenterer dem tidsmæssigt. Ud fra dette træffer jeg realistiske beslutninger om kapacitet og identificerer ineffektive rutiner, såsom dårligt timede sikkerhedskopieringer. Den, der har ansvaret for Linux-servere, får med denne metode en pålidelig oversigt og sparer tid i forbindelse med analyse, planlægning og drift.
