En bra larmtröskel för en server slår till när en människa behöver agera och håller tyst annars. I praktiken betyder det att du larmar på värden som håller i sig i stället för enstaka toppar, mäter lasten per CPU-kärna i stället för som ett råvärde, bevakar tillgängligt minne och swap i stället för ”använt RAM”, larmar tidigt om diskutrymme och om hur snabbt det växer, och behandlar varje oplanerad omstart som något du vill veta om. Dela upp larmen i en varningsnivå för arbetstid och en kritisk nivå som får väcka någon, och se över siffrorna efter varje incident.
Den här guiden går igenom varje mätvärde, förklarar hur en meningsfull tröskel ser ut och avslutas med en tabell med startvärden. De är utgångspunkter, inte regler: varje server har sitt eget normalläge, och rätt tröskel är den som matchar det.
Vad en tröskel är till för
Varje larm kostar uppmärksamhet. Ett larm som slår till utan att kräva någon åtgärd lär folk att strunta i nästa, och nästa kan vara på riktigt. Svara på tre frågor innan du sätter en tröskel:
Vad går sönder om värdet fortsätter så här, och hur snart?
Vad skulle personen som får larmet faktiskt göra?
Kan det vänta till i morgon bitti?
Om ingenting går sönder och ingen skulle agera är det en graf, inte ett larm. Om det kan vänta till morgonen är det en varning. Bara det som inte kan vänta ska nå en telefon mitt i natten.
Varningsnivå och kritisk nivå
Två nivåer per mätvärde fungerar bra för de flesta team:
Varning: något är på väg åt fel håll. Skicka det till e-post eller en chattkanal för teamet och hantera det under arbetstid.
Kritisk: ett avbrott är nära eller redan pågår. Skicka det som en pushnotis till den som har jour, dag som natt.
Om ditt övervakningsverktyg har en tröskel per mätvärde kan du få samma effekt med routning: sätt tröskeln där en åtgärd behövs och välj kanal per server. Ett disklarm på en staging-maskin kan gå till e-post, medan samma larm på produktionsdatabasen går till jourteamets chatt. I Uptimecheck väljs aviseringar per monitor, vilket gör den uppdelningen enkel. Med jourscheman når pushlarmen den som har jour just nu, och eskalering kan hålla tillbaka en kanal i 5 till 60 minuter och bara larma om problemet fortfarande pågår och ingen har kvitterat det.
Varaktighet slår toppar
Den vanligaste källan till brus är att larma på en enda avläsning. CPU på 100 procent i tio sekunder under en driftsättning, en backup eller en omgenerering av cachen är normalt. CPU på 100 procent i tjugo minuter är det inte. Lägg till en varaktighet där verktyget tillåter det: ”över 90 procent i 10 minuter” i stället för ”över 90 procent”.
Där det inte går kan du använda mätvärden som redan jämnas ut över tid. Lastmedelvärdet för 15 minuter är ett bra exempel: en kort topp rubbar det knappt, medan en ihållande överbelastning trycker upp det och håller det där.
CPU
Hög CPU är sällan ett problem i sig. En server som jobbar hårt gör det den ska. CPU blir ett problem när den är mättad så länge att förfrågningar köar och svarstiderna stiger. Larma på ihållande belastning och titta på den tillsammans med svarstiderna från dina upptidskontroller. Om CPU ligger på 95 procent och svarstiderna är oförändrade har servern mycket att göra, men den fallerar inte.
Lastmedelvärde per kärna
På Linux är lastmedelvärdet ungefär antalet processer som kör eller väntar på CPU, och på Linux även de som väntar på disk-I/O, i genomsnitt över 1, 5 och 15 minuter. En rå last på 4 säger ingenting i sig: på en server med 16 kärnor är det lite, på en server med 2 kärnor är det dubbelt så mycket som maskinen klarar. Dela med antalet kärnor innan du jämför, vilket nproc visar.
Värdet för 1 minut reagerar snabbt och är brusigt. Använd det för felsökning, inte för larm.
Värdet för 15 minuter är det du ska larma på. Över 1 per kärna betyder att arbete köar; långt över det, under lång tid, betyder att användarna märker det.
Hög last med låg CPU betyder oftast processer som väntar på disk eller nätverkslagring. Titta på I/O, inte på koden.
RAM och swap
”Använt RAM” är ett missvisande mätvärde på Linux. Kärnan använder ledigt minne till filcachen och lämnar tillbaka det när program behöver det, så en frisk server visar ofta nästan fullt minne. Titta i stället på tillgängligt minne, kolumnen ”available” i free -m, som räknar med den cache som kan frigöras.
Swap säger mer. En server som normalt inte swappar och börjar göra det är under minnestryck, och prestandan rasar när aktivt minne börjar skrivas till disk. Två användbara signaler:
Swap som dyker upp eller växer på en server som normalt inte har någon.
Tillgängligt minne som minskar stadigt under flera dagar, vilket ofta tyder på en läcka i en process som körs länge.
Databasservrar är ett specialfall: de är medvetet konfigurerade för att använda det mesta av minnet. Sätt deras trösklar utifrån vad du ser under en vanlig vecka.
Diskutrymme och tillväxt
En full disk är en av de vanligaste orsakerna till avbrott som hade gått att undvika. Databaser slutar skriva, loggar slutar roteras, sessioner kan inte sparas och backuper misslyckas. Disk är också det enklaste mätvärdet att få rätt, eftersom det sällan ändras snabbt, vilket ger tid att agera om du larmar tidigt.
Använd en procenttröskel för varning och kritisk nivå, men anpassa den efter storleken. På en volym på 2 TB är 10 procent ledigt fortfarande 200 GB; på en volym på 20 GB är det 2 GB, vilket en enda skenande logg kan äta upp på en eftermiddag.
Bevaka tillväxten, inte bara nivån. En disk på 70 procent som har ökat 10 procentenheter den här veckan är mer brådskande än en som har legat på 85 procent i ett år.
Ta reda på vad som fyller den: loggar, backuper som sparas lokalt, uppladdningar, Docker-avbilder, databasfiler. Varje sak har sin egen lösning.
Nätverk
Det är svårt att sätta en fast tröskel för nätverkstrafik, eftersom det normala varierar med tid på dygnet och säsong. Två mönster är värda ett larm. Trafik långt över den vanliga nivån, nära länkens kapacitet, kan betyda en trafiktopp, en skrapare eller en attack. Trafik som sjunker till nästan noll på en server som normalt har mycket att göra kan betyda att den har plockats ur lastbalanseraren eller tappat nätverket, även om själva maskinen ser frisk ut. Lär dig det normala intervallet från några veckors historik innan du sätter siffror.
Omstarter
En oplanerad omstart är alltid värd att känna till. Det kan vara en kärnuppdatering, underhåll hos hostingleverantören, en krasch eller att minnet tog slut. Även när allt kommer tillbaka kan tjänster som inte är inställda på att starta vid uppstart, schemalagda jobb som skulle ha körts under omstarten och monterade volymer hamna i ett dåligt läge. Larma på varje omstart utanför ett underhållsfönster, på varningsnivå om servern återhämtade sig av sig själv.
Startvärden
Värdena nedan är exempel på utgångspunkter för en typisk webb- eller applikationsserver. Använd dem de första veckorna och justera dem sedan efter vad du ser.
MätvärdeVarning (exempel)Kritisk (exempel)CPUÖver 85 % i 15 minuterÖver 95 % i 15 minuter, med stigande svarstiderLastmedelvärde (15 min)Över 1 per kärnaÖver 2 per kärnaTillgängligt minneUnder 15 %Under 5 %SwapAll användning på en server som normalt inte har någonÖver 50 % av swap användsDiskÖver 80 %, eller full inom en vecka i nuvarande taktÖver 90 %, eller full inom ett dygnNätverkLångt utanför det normala intervallet för tiden på dygnetNära länkens kapacitet, eller nära noll på en upptagen serverOmstartVarje omstart utanför ett underhållsfönsterTjänster kom inte tillbaka efter en omstart
Uptimechecks serverövervakning rapporterar CPU, minne, disk och nätverk varje minut på Linux, macOS och Windows. Du sätter trösklar för CPU, minne och disk per server, med en varaktighet som 5 eller 15 minuter, och du larmas också vid omstarter och när en server tystnar, så att en maskin som har slutat rapportera aldrig misstas för en lugn. Vill du veta mer om varför de här siffrorna spelar roll kan du läsa håll webbplatsen igång med övervakning av serverstatus.
Bevaka symptomen också
Servermätvärden beskriver orsaker. Dina användare upplever symptom: långsamma sidor, fel och misslyckade jobb. Övervaka båda. En upptidskontroll med validering av svaret talar om när webbplatsen fallerar, och en heartbeat talar om när backupen inte blev klar. När ett symptomlarm och ett resurslarm slår till samtidigt är orsaken oftast uppenbar. När bara resurslarmet slår till har du ofta tid att åtgärda det innan någon märker något.
Det gör också att du tryggt kan höja servertrösklarna. Om webbplatsen kontrolleras varje minut behöver inte ett CPU-larm vara det som fångar ett avbrott. Det kan ställas in för tidig varning i stället för som sista utväg. Samma tänkande gäller för kontroller av webbplatser; läs hur du minskar falsklarm i upptidsövervakningen.
Se över trösklarna efter incidenter
Trösklar blir aldrig färdiga. Efter varje incident, och en gång i månaden för servrar som larmar mycket, fråga:
Slog ett larm till innan användarna märkte något? Om inte, vilket mätvärde rörde sig först, och kunde en lägre tröskel ha fångat det?
Vilka larm slog till utan att någon agerade? Höj dem, lägg till en varaktighet eller flytta dem till en kanal för dagtid.
Nådde larmet någon som kunde agera? Om inte, ändra routningen.
Har serverns normalläge ändrats efter en uppgradering, en migrering eller mer trafik?
Skriv in svaren i incidentrapporten, så att ändringen har ett skäl kopplat till sig. Mallen för incidentgenomgångar har ett avsnitt för just detta.
Sammanfattning
Larma på det som kräver en människa, med den brådska det verkligen har. Använd ihållande värden, last per kärna, tillgängligt minne och swap, disknivå och tillväxt samt varje oplanerad omstart. Börja med exempelvärden, lär dig varje servers normalläge och finjustera efter varje incident.
Uptimecheck samlar serverövervakning, upptidskontroller, heartbeats och statussidor i ett och samma konto. Starta en kostnadsfri provperiod på 14 dagar, inget kreditkort behövs.