En god varslingsterskel for en server utløses når noen faktisk må gjøre noe, og holder seg stille ellers. I praksis betyr det å varsle på vedvarende verdier i stedet for enkeltstående topper, måle last per CPU-kjerne i stedet for som et rått tall, følge med på tilgjengelig minne og swap i stedet for «brukt RAM», varsle tidlig om diskplass og om hvor fort den vokser, og behandle hver uplanlagte omstart som noe du bør vite om. Del varslene inn i et advarselsnivå for arbeidstiden og et kritisk nivå som kan vekke noen, og gå gjennom tallene etter hver hendelse.
Denne guiden går gjennom hver måleverdi, forklarer hvordan en meningsfull terskel ser ut og avslutter med en tabell over startverdier. De er utgangspunkter, ikke regler: hver server har sitt eget normalnivå, og riktig terskel er den som passer til det.
Hva en terskel er til for
Hvert varsel koster oppmerksomhet. Et varsel som utløses uten at noe må gjøres, lærer folk å overse det neste, og det neste kan være ekte. Før du setter en terskel, bør du svare på tre spørsmål:
Hva går i stykker hvis denne verdien fortsetter i samme retning, og hvor snart?
Hva ville den som mottar varselet, faktisk gjort?
Kan det vente til i morgen tidlig?
Hvis ingenting går i stykker og ingen ville reagert, hører det hjemme i en graf, ikke i et varsel. Hvis det kan vente til morgenen, er det en advarsel. Bare det som ikke kan vente, bør nå en telefon om natten.
Advarsel og kritisk nivå
To nivåer per måleverdi fungerer godt for de fleste team:
Advarsel: noe beveger seg i feil retning. Send det til e-post eller en chattekanal for teamet, og ta det i arbeidstiden.
Kritisk: et driftsavbrudd er nær eller allerede i gang. Send det som pushvarsel til den som har vakt, dag og natt.
Hvis overvåkingsverktøyet ditt har én terskel per måleverdi, oppnår du det samme med ruting: sett terskelen der det må handles, og velg kanal per server. Et diskvarsel på en staging-server kan gå til e-post; det samme varselet på produksjonsdatabasen kan gå til vaktteamets chat. I Uptimecheck velges varslinger per monitor, noe som gjør den inndelingen enkel. Med vaktplaner når pushvarsler den som har vakt akkurat nå, og eskalering kan holde en kanal tilbake i 5 til 60 minutter og bare varsle hvis problemet fortsatt pågår og ingen har kvittert for det.
Varighet slår topper
Den vanligste kilden til støy er å varsle på én enkelt måling. CPU på 100 prosent i ti sekunder under en utrulling, en sikkerhetskopi eller en gjenoppbygging av hurtigbufferen er normalt. CPU på 100 prosent i tjue minutter er det ikke. Der verktøyet ditt tillater det, bør du legge til en varighet: «over 90 prosent i 10 minutter» i stedet for «over 90 prosent».
Der det ikke går, bruker du måleverdier som allerede jevner seg ut over tid. Lastsnittet over 15 minutter er et godt eksempel: en kort topp flytter det knapt, mens en vedvarende overbelastning presser det opp og holder det der.
CPU
Høy CPU-bruk er sjelden et problem i seg selv. En travel server er en server som gjør jobben sin. CPU blir et problem når den er mettet lenge nok til at forespørsler havner i kø og responstidene stiger. Varsle på vedvarende bruk, og se den i sammenheng med responstidene fra oppetidssjekkene dine. Hvis CPU ligger på 95 prosent og responstidene er stabile, er serveren travel, ikke i ferd med å svikte.
Lastsnitt per kjerne
På Linux er lastsnittet omtrent antallet prosesser som kjører eller venter på CPU, og på Linux også de som venter på disk-I/O, i snitt over 1, 5 og 15 minutter. En rå last på 4 sier ingenting alene: på en server med 16 kjerner er den lav, på en server med 2 kjerner er den det dobbelte av hva maskinen klarer. Del på antall kjerner før du sammenligner; det forteller nproc deg.
1-minuttsverdien reagerer raskt og er full av støy. Bruk den til feilsøking, ikke til varsler.
15-minuttsverdien er den du bør varsle på. Over 1 per kjerne betyr at arbeid havner i kø; godt over det, over lang tid, betyr at brukerne merker det.
Høy last med lav CPU-bruk betyr som regel prosesser som venter på disk eller nettverkslagring. Se på I/O, ikke på koden.
RAM og swap
«Brukt RAM» er en misvisende måleverdi på Linux. Kjernen bruker ledig minne til filhurtigbufferen og gir det tilbake når applikasjonene trenger det, så en frisk server viser ofte nesten fullt minne. Se heller på tilgjengelig minne, kolonnen «available» i free -m, som tar med hurtigbufferen som kan frigjøres.
Swap sier mer. En server som normalt ikke swapper og begynner å gjøre det, er under minnepress, og ytelsen faller kraftig når aktivt minne flyttes ut til disk. To nyttige signaler:
Swap-bruk som dukker opp eller vokser på en server som vanligvis ikke har noen.
Tilgjengelig minne som faller jevnt over flere dager, noe som ofte tyder på en lekkasje i en prosess som kjører lenge.
Databaseservere er et spesialtilfelle: de er satt opp til å bruke det meste av minnet med vilje. Sett tersklene deres ut fra det du ser i en normal uke.
Diskplass og vekst
En full disk er en av de vanligste årsakene til driftsavbrudd som kunne vært unngått. Databaser slutter å skrive, logger roteres ikke lenger, økter kan ikke lagres og sikkerhetskopier feiler. Disk er også den enkleste måleverdien å treffe riktig på, fordi den sjelden endrer seg raskt, og det gir tid til å handle hvis du varsler tidlig.
Bruk en prosentterskel for advarsel og kritisk, men juster den etter størrelsen. På et volum på 2 TB er 10 prosent ledig fortsatt 200 GB; på et volum på 20 GB er det 2 GB, som én løpsk logg kan spise opp på en ettermiddag.
Følg med på veksten i tillegg til nivået. En disk på 70 prosent som har vokst 10 prosentpoeng denne uken, haster mer enn en som har ligget på 85 prosent i et år.
Vit hva som fyller den: logger, sikkerhetskopier som lagres lokalt, opplastinger, Docker-images, databasefiler. Hver av dem har sin egen løsning.
Nettverk
Det er vanskelig å sette en fast terskel for nettverkstrafikk, fordi det normale varierer med tid på døgnet og sesong. To mønstre er verdt et varsel. Trafikk langt over det vanlige nivået, nær kapasiteten på linjen, kan bety en trafikktopp, en scraper eller et angrep. Trafikk som faller til nesten null på en server som normalt er travel, kan bety at den er tatt ut av lastbalansereren eller har mistet nettverket, selv om selve maskinen ser fin ut. Lær deg det normale området fra noen ukers historikk før du setter tall.
Omstarter
En uplanlagt omstart er alltid verdt å vite om. Det kan være en kjerneoppdatering, vedlikehold hos hostingleverandøren, et krasj eller en hendelse der minnet gikk tomt. Selv når alt kommer opp igjen, kan tjenester som ikke er satt til å starte ved oppstart, planlagte jobber som skulle kjørt under omstarten og monterte volumer bli liggende i en dårlig tilstand. Varsle på hver omstart utenfor et vedlikeholdsvindu, på advarselsnivå hvis serveren kom seg av seg selv.
Startverdier
Verdiene nedenfor er eksempler på utgangspunkter for en typisk web- eller applikasjonsserver. Bruk dem de første ukene, og juster dem deretter etter det du observerer.
MåleverdiAdvarsel (eksempel)Kritisk (eksempel)CPUOver 85 % i 15 minutterOver 95 % i 15 minutter, med stigende responstiderLastsnitt (15 min)Over 1 per kjerneOver 2 per kjerneTilgjengelig minneUnder 15 %Under 5 %SwapAll bruk på en server som normalt ikke har noenOver 50 % av swap i brukDiskOver 80 %, eller full innen en uke i dagens tempoOver 90 %, eller full innen et døgnNettverkGodt utenfor det normale området for tiden på døgnetNær linjekapasiteten, eller nær null på en travel serverOmstartEnhver omstart utenfor et vedlikeholdsvinduTjenestene kom ikke opp igjen etter en omstart
Serverovervåking i Uptimecheck rapporterer CPU, minne, disk og nettverk hvert minutt på Linux, macOS og Windows. Du setter terskler for CPU, minne og disk per server, med en varighet som 5 eller 15 minutter, og du blir også varslet om omstarter og når en server blir stille, slik at en maskin som har sluttet å rapportere, aldri forveksles med en som bare har lite å gjøre. Vil du vite mer om hvorfor disse tallene betyr noe, kan du lese hvordan du holder nettstedet i gang med overvåking av serverstatus.
Følg med på symptomene også
Servermålinger beskriver årsaker. Brukerne dine opplever symptomer: trege sider, feil og jobber som ikke blir kjørt. Overvåk begge deler. En oppetidssjekk med validering av svaret forteller deg når nettstedet svikter, og en heartbeat forteller deg når sikkerhetskopien ikke ble ferdig. Når et symptomvarsel og et ressursvarsel utløses samtidig, er årsaken som regel åpenbar. Når bare ressursvarselet utløses, har du ofte tid til å rette det før noen merker noe.
Det gjør det også trygt å heve serverterskler. Hvis nettstedet sjekkes hvert minutt, trenger ikke et CPU-varsel å være det som fanger opp et driftsavbrudd. Det kan stilles inn som et tidlig varsel i stedet for en siste utvei. Samme tankegang gjelder sjekker av nettsteder; se hvordan du reduserer falske varsler i oppetidsovervåking.
Gå gjennom tersklene etter hendelser
Terskler blir aldri ferdige. Etter hver hendelse, og en gang i måneden for servere med mye støy, bør du spørre:
Ble det utløst et varsel før brukerne merket noe? Hvis ikke: hvilken måleverdi beveget seg først, og kunne en lavere terskel ha fanget det opp?
Hvilke varsler ble utløst uten at noen gjorde noe? Hev dem, legg til en varighet eller flytt dem til en kanal for dagtid.
Nådde varselet noen som kunne handle? Hvis ikke, endre rutingen.
Har serverens normalnivå endret seg etter en oppgradering, en migrering eller mer trafikk?
Skriv svarene inn i hendelsesrapporten, slik at endringen har en begrunnelse. Malen for postmortem etter hendelser har en egen del for akkurat dette.
Oppsummering
Varsle om det som trenger et menneske, med den hastegraden det faktisk har. Bruk vedvarende verdier, last per kjerne, tilgjengelig minne og swap, disknivå og vekst, og hver uplanlagte omstart. Begynn med eksempelverdier, lær deg hver servers normalnivå og juster etter hver hendelse.
Uptimecheck samler serverovervåking, oppetidssjekker, heartbeats og statussider i én konto. Start en gratis prøveperiode på 14 dager, uten kredittkort.