En god alarmtærskel for en server udløses, når et menneske skal gøre noget, og holder sig ellers i ro. I praksis betyder det, at du alarmerer på vedvarende værdier frem for enkelte spidser, måler load pr. CPU-kerne frem for som et råt tal, holder øje med tilgængelig hukommelse og swap frem for “brugt RAM”, alarmerer tidligt på diskplads og på, hvor hurtigt den vokser, og behandler enhver uplanlagt genstart som noget, du bør vide. Del alarmerne op i et advarselsniveau til arbejdstiden og et kritisk niveau, der må vække nogen, og gennemgå tallene efter hver hændelse.
Denne guide gennemgår hver metrik, forklarer, hvordan en meningsfuld tærskel ser ud, og slutter med en tabel med startværdier. Det er udgangspunkter, ikke regler: Hver server har sit eget normale niveau, og den rigtige tærskel er den, der passer til det.
Hvad en tærskel skal bruges til
Hver alarm koster opmærksomhed. En alarm, der udløses uden at kræve handling, lærer folk at ignorere den næste, og den næste kan være ægte. Før du sætter en tærskel, så besvar tre spørgsmål:
Hvad går i stykker, hvis værdien fortsætter, og hvor hurtigt?
Hvad ville den, der modtager alarmen, egentlig gøre?
Kan det vente til i morgen tidlig?
Hvis intet går i stykker, og ingen ville gøre noget, er det en graf, ikke en alarm. Hvis det kan vente til i morgen, er det en advarsel. Kun det, der ikke kan vente, bør nå en telefon om natten.
Advarsel og kritisk niveau
To niveauer pr. metrik fungerer godt for de fleste teams:
Advarsel: Noget bevæger sig i den forkerte retning. Send den til e-mail eller en kanal i teamets chat, og tag dig af den i arbejdstiden.
Kritisk: Et nedbrud er tæt på eller allerede i gang. Send den som push-notifikation til den, der har vagten, uanset tidspunkt på døgnet.
Hvis dit overvågningsværktøj kun har én tærskel pr. metrik, kan du opnå det samme med routing: Sæt tærsklen der, hvor der skal handles, og vælg kanalen pr. server. En diskalarm på en staging-server kan gå til e-mail, mens den samme alarm på produktionsdatabasen kan gå til vagtteamets chat. I Uptimecheck vælges notifikationer pr. monitor, hvilket gør den opdeling enkel. Med vagtplaner når push-alarmer den, der har vagten lige nu, og eskalering kan holde en kanal tilbage i 5 til 60 minutter og kun alarmere, hvis problemet stadig står på, og ingen har kvitteret for det.
Varighed slår spidser
Den mest almindelige kilde til støj er at alarmere på en enkelt måling. CPU på 100 procent i ti sekunder under en udrulning, en backup eller en genopbygning af cachen er normalt. CPU på 100 procent i tyve minutter er ikke. Hvor dit værktøj tillader det, så tilføj en varighed: “over 90 procent i 10 minutter” i stedet for “over 90 procent”.
Hvor det ikke kan, så brug metrikker, der allerede udjævner over tid. Load average over 15 minutter er et godt eksempel: Et kort udbrud rykker den knap, mens en vedvarende overbelastning skubber den op og holder den der.
CPU
Høj CPU er sjældent et problem i sig selv. En travl server er en server, der gør sit arbejde. CPU bliver et problem, når den er mættet så længe, at forespørgsler hober sig op i kø, og svartiderne stiger. Alarmér på vedvarende forbrug, og se på det sammen med svartiderne fra dine oppetidstjek. Hvis CPU ligger på 95 procent, og svartiderne er flade, har serveren travlt, men den fejler ikke.
Load average pr. kerne
På Linux er load average groft sagt antallet af processer, der kører eller venter på CPU, og på Linux også dem, der venter på disk-I/O, i gennemsnit over 1, 5 og 15 minutter. En rå load på 4 betyder intet i sig selv: På en server med 16 kerner er den lav, på en server med 2 kerner er den dobbelt så høj, som maskinen kan klare. Dividér med antallet af kerner, før du sammenligner. Det fortæller nproc dig.
Værdien for 1 minut reagerer hurtigt og er støjende. Brug den til fejlsøgning, ikke til alarmer.
Værdien for 15 minutter er den, du skal alarmere på. Over 1 pr. kerne betyder, at arbejdet står i kø; et godt stykke derover i længere tid betyder, at brugerne mærker det.
Høj load med lav CPU betyder som regel processer, der venter på disk eller netværkslagring. Kig på I/O, ikke på koden.
RAM og swap
“Brugt RAM” er en misvisende metrik på Linux. Kernen bruger ledig hukommelse til filcachen og giver den tilbage, når programmerne har brug for den, så en sund server viser ofte næsten fuld hukommelse. Se i stedet på tilgængelig hukommelse, kolonnen “available” i free -m, som medregner den cache, der kan frigøres.
Swap fortæller dig mere. En server, der normalt ikke swapper og begynder at gøre det, er under pres på hukommelsen, og ydeevnen falder brat, så snart aktiv hukommelse bliver flyttet ud på disken. To nyttige signaler:
Swap-forbrug, der dukker op eller vokser på en server, som normalt ikke har noget.
Tilgængelig hukommelse, der falder støt over flere dage, hvilket ofte peger på en lækage i en proces, der kører længe.
Databaseservere er et særtilfælde: De er bevidst sat op til at bruge det meste af hukommelsen. Sæt deres tærskler ud fra det, du ser i en normal uge.
Diskplads og vækst
En fuld disk er en af de mest almindelige årsager til nedbrud, der kunne være undgået. Databaser holder op med at skrive, logrotation stopper, sessioner kan ikke gemmes, og backups fejler. Disk er også den letteste metrik at ramme rigtigt, fordi den sjældent ændrer sig hurtigt, så der er tid til at handle, hvis du alarmerer tidligt.
Brug en procenttærskel for advarsel og kritisk, men tilpas den efter størrelsen. På et volumen på 2 TB er 10 procent ledigt stadig 200 GB; på et volumen på 20 GB er det 2 GB, som én løbsk log kan æde på en eftermiddag.
Hold øje med væksten såvel som niveauet. En disk på 70 procent, der er vokset 10 procentpoint i denne uge, haster mere end en, der har ligget på 85 procent i et år.
Vid, hvad der fylder den: logs, lokalt gemte backups, uploads, Docker-images, databasefiler. Hver har sin egen løsning.
Netværk
Det er svært at sætte en fast tærskel for netværkstrafik, fordi det normale varierer med tidspunktet på dagen og sæsonen. To mønstre er værd at alarmere på. Trafik langt over det sædvanlige niveau, tæt på forbindelsens kapacitet, kan betyde en trafikspids, en scraper eller et angreb. Trafik, der falder til næsten nul på en server, der normalt har travlt, kan betyde, at den er taget ud af load balanceren eller har mistet netværket, selv om selve maskinen ser fin ud. Lær det normale spænd at kende ud fra et par ugers historik, før du sætter tal på.
Genstarter
En uplanlagt genstart er altid værd at kende til. Det kan være en kerneopdatering, vedligeholdelse hos hostingudbyderen, et nedbrud eller en hændelse med opbrugt hukommelse. Selv når alt kommer op igen, kan tjenester, der ikke er sat til at starte ved opstart, planlagte job, der skulle have kørt under genstarten, og monterede volumener stå tilbage i en dårlig tilstand. Alarmér på hver genstart uden for et vedligeholdelsesvindue, på advarselsniveau, hvis serveren kom sig af sig selv.
Startværdier
Værdierne nedenfor er eksempler på udgangspunkter for en typisk web- eller applikationsserver. Brug dem de første par uger, og tilpas dem derefter til det, du observerer.
MetrikAdvarsel (eksempel)Kritisk (eksempel)CPUOver 85 % i 15 minutterOver 95 % i 15 minutter, med stigende svartiderLoad average (15 min)Over 1 pr. kerneOver 2 pr. kerneTilgængelig hukommelseUnder 15 %Under 5 %SwapEthvert forbrug på en server, der normalt ikke har nogetOver 50 % af swap i brugDiskOver 80 %, eller fuld inden for en uge med den nuværende vækstOver 90 %, eller fuld inden for et døgnNetværkEt godt stykke uden for det normale spænd for tidspunktet på dagenTæt på forbindelsens kapacitet, eller næsten nul på en travl serverGenstartEnhver genstart uden for et vedligeholdelsesvindueTjenester kom ikke op igen efter en genstart
Serverovervågning i Uptimecheck rapporterer CPU, hukommelse, disk og netværk hvert minut på Linux, macOS og Windows. Du sætter tærskler for CPU, hukommelse og disk pr. server med en varighed som 5 eller 15 minutter, og du får også besked ved genstarter, og når en server går i stå med at rapportere, så en maskine, der er holdt op med at sende data, aldrig forveksles med en rolig maskine. Vil du vide mere om, hvorfor de tal betyder noget, så læs hold dit website kørende med overvågning af serverstatus.
Hold også øje med symptomerne
Servermetrikker beskriver årsager. Dine brugere oplever symptomer: langsomme sider, fejl og job, der fejler. Overvåg begge dele. Et oppetidstjek med validering af svaret fortæller dig, når sitet fejler, og et heartbeat fortæller dig, når backuppen ikke blev færdig. Når en symptomalarm og en ressourcealarm udløses samtidig, er årsagen som regel åbenlys. Når kun ressourcealarmen udløses, har du ofte tid til at rette det, før nogen opdager noget.
Det gør det også muligt at hæve servertærsklerne med ro i maven. Hvis sitet tjekkes hvert minut, behøver en CPU-alarm ikke at være det, der fanger et nedbrud. Den kan i stedet indstilles som tidlig advarsel frem for sidste udvej. Samme tankegang gælder for tjek af websites; se sådan reducerer du falske alarmer i oppetidsovervågning.
Gennemgå tærsklerne efter hændelser
Tærskler bliver aldrig færdige. Efter hver hændelse, og en gang om måneden for støjende servere, så spørg:
Gik der en alarm, før brugerne opdagede noget? Hvis ikke, hvilken metrik flyttede sig først, og kunne en lavere tærskel have fanget det?
Hvilke alarmer gik, uden at nogen gjorde noget? Hæv dem, tilføj en varighed, eller flyt dem til en kanal, der kun bruges om dagen.
Nåede alarmen frem til en, der kunne handle? Hvis ikke, så ændr routingen.
Har serverens normale niveau ændret sig efter en opgradering, en migrering eller mere trafik?
Skriv svarene ind i hændelsesrapporten, så ændringen har en begrundelse knyttet til sig. Skabelonen til postmortems har en sektion til netop det.
Opsummering
Alarmér på det, der kræver et menneske, med den grad af hast, det reelt har. Brug vedvarende værdier, load pr. kerne, tilgængelig hukommelse og swap, diskens niveau og vækst samt enhver uplanlagt genstart. Start med eksempelværdier, lær hver servers normale niveau at kende, og finjustér efter hver hændelse.
Uptimecheck samler serverovervågning, oppetidstjek, heartbeats og statussider i én konto. Start en gratis prøveperiode på 14 dage, intet kreditkort påkrævet.