Een goede alertdrempel voor een server gaat af wanneer iemand in actie moet komen, en blijft verder stil. In de praktijk betekent dat: alarmeren op aanhoudende waarden in plaats van losse pieken, load per CPU-core meten in plaats van als ruw getal, kijken naar beschikbaar geheugen en swap in plaats van “gebruikt RAM”, vroeg alarmeren op schijfruimte en op hoe snel die groeit, en elke ongeplande reboot de moeite waard vinden om te weten. Splits alerts in een waarschuwingsniveau voor werktijd en een kritiek niveau dat iemand mag wekken, en evalueer de waarden na elk incident.
Deze gids loopt elke metric langs, legt uit hoe een zinvolle drempel eruitziet en sluit af met een tabel met startwaarden. Het zijn vertrekpunten, geen regels: elke server heeft zijn eigen normaal, en de juiste drempel is de drempel die daarbij past.
Waar een drempel voor dient
Elke alert kost aandacht. Een alert die afgaat zonder dat er iets hoeft te gebeuren, leert mensen de volgende te negeren, en die volgende kan echt zijn. Beantwoord drie vragen voordat je een drempel instelt:
Wat gaat er stuk als deze waarde zo doorloopt, en hoe snel?
Wat zou de persoon die de alert ontvangt concreet doen?
Kan het wachten tot de ochtend?
Gaat er niets stuk en zou niemand iets doen, dan is het een grafiek, geen alert. Kan het wachten tot de ochtend, dan is het een waarschuwing. Alleen wat niet kan wachten, hoort ’s nachts op een telefoon te belanden.
Waarschuwing en kritiek
Twee niveaus per metric werken voor de meeste teams goed:
Waarschuwing: iets beweegt de verkeerde kant op. Stuur het naar e-mail of een teamchatkanaal en pak het op tijdens werktijd.
Kritiek: een storing dreigt of is al bezig. Stuur het als pushmelding naar wie er dienst heeft, dag en nacht.
Heeft je monitoringtool één drempel per metric, dan bereik je hetzelfde met routering: leg de drempel waar actie nodig is en kies het kanaal per server. Een schijfalert op een stagingserver kan naar e-mail; dezelfde alert op de productiedatabase kan naar de chat van het team met dienst. Bij Uptimecheck kies je de meldingen per monitor, wat die splitsing eenvoudig maakt. Met dienstroosters bereiken pushalerts wie er op dat moment dienst heeft, en escalatie kan een kanaal 5 tot 60 minuten achterhouden en pas alarmeren als het probleem nog speelt en niemand het heeft bevestigd.
Duur wint van pieken
De meest voorkomende bron van ruis is alarmeren op één enkele meting. CPU op 100 procent gedurende tien seconden tijdens een deployment, een back-up of het opnieuw opbouwen van een cache is normaal. CPU op 100 procent gedurende twintig minuten niet. Voeg waar je tool dat toelaat een duur toe: “boven 90 procent gedurende 10 minuten” in plaats van “boven 90 procent”.
Kan dat niet, gebruik dan metrics die zelf al over tijd uitmiddelen. Het load average over 15 minuten is een goed voorbeeld: een korte uitschieter verandert er nauwelijks iets aan, terwijl een aanhoudende overbelasting het omhoog duwt en daar houdt.
CPU
Een hoge CPU is op zich zelden een probleem. Een drukke server is een server die zijn werk doet. CPU wordt pas een probleem als die zo lang verzadigd blijft dat requests in de wachtrij komen en responstijden oplopen. Alarmeer op aanhoudend gebruik en bekijk het samen met de responstijden uit je uptimechecks. Staat de CPU op 95 procent en blijven de responstijden vlak, dan is de server druk, niet aan het falen.
Load average per core
Op Linux is het load average grofweg het aantal processen dat draait of op de CPU wacht, en op Linux ook de processen die op schijf-I/O wachten, gemiddeld over 1, 5 en 15 minuten. Een ruwe load van 4 zegt op zich niets: op een server met 16 cores is dat licht, op een server met 2 cores is het twee keer zoveel als de machine aankan. Deel door het aantal cores voordat je vergelijkt; nproc vertelt je hoeveel dat er zijn.
De waarde over 1 minuut reageert snel en is onrustig. Gebruik die voor diagnose, niet voor alerts.
Op de waarde over 15 minuten moet je alarmeren. Boven 1 per core betekent dat er werk in de wachtrij staat; ruim daarboven, gedurende lange tijd, betekent dat gebruikers het merken.
Een hoge load bij een lage CPU betekent meestal dat processen op schijf- of netwerkopslag wachten. Kijk naar I/O, niet naar code.
RAM en swap
“Gebruikt RAM” is op Linux een misleidende metric. De kernel gebruikt vrij geheugen voor de bestandscache en geeft het terug zodra applicaties het nodig hebben, dus een gezonde server toont vaak een bijna vol geheugen. Kijk in plaats daarvan naar het beschikbare geheugen, de kolom “available” in free -m, die de cache meetelt die kan worden vrijgegeven.
Swap zegt meer. Een server die normaal niet swapt en daar wel mee begint, staat onder geheugendruk, en de prestaties zakken flink in zodra actief geheugen naar schijf wordt weggeschreven. Twee bruikbare signalen:
Swapgebruik dat opduikt of groeit op een server die normaal geen swap gebruikt.
Beschikbaar geheugen dat over meerdere dagen gestaag daalt, wat vaak wijst op een lek in een langlopend proces.
Databaseservers zijn een apart geval: die zijn bewust zo ingesteld dat ze het grootste deel van het geheugen gebruiken. Baseer hun drempels op wat je in een normale week ziet.
Schijfruimte en groei
Een volle schijf is een van de meest voorkomende oorzaken van vermijdbare storingen. Databases stoppen met schrijven, logs worden niet meer geroteerd, sessies kunnen niet worden opgeslagen en back-ups mislukken. Schijfruimte is ook de makkelijkste metric om goed in te stellen, omdat die zelden snel verandert. Alarmeer je vroeg, dan heb je tijd om in te grijpen.
Gebruik een percentage als drempel voor waarschuwing en kritiek, maar stem het af op de grootte. Op een volume van 2 TB is 10 procent vrij nog altijd 200 GB; op een volume van 20 GB is het 2 GB, en dat vreet één ontspoorde log in een middag op.
Let op de groei, niet alleen op het niveau. Een schijf op 70 procent die deze week 10 punten groeide, is urgenter dan een schijf die al een jaar op 85 procent staat.
Weet wat de schijf vult: logs, lokaal bewaarde back-ups, uploads, Docker-images, databasebestanden. Elk daarvan vraagt om een andere oplossing.
Netwerk
Voor netwerkverkeer is een vaste drempel lastig, omdat het normale niveau verschilt per tijdstip en per seizoen. Twee patronen verdienen een alert. Verkeer ver boven het gebruikelijke niveau, dicht bij de capaciteit van de verbinding, kan wijzen op een verkeerspiek, een scraper of een aanval. Verkeer dat bijna tot nul zakt op een server die normaal druk is, kan betekenen dat die uit de load balancer is gehaald of zijn netwerk kwijt is, ook als de machine zelf in orde lijkt. Leer het normale bereik kennen uit een paar weken historie voordat je getallen instelt.
Reboots
Een ongeplande reboot wil je altijd weten. Het kan een kernelupdate zijn, onderhoud bij een hostingprovider, een crash of een out-of-memory-situatie. Ook als alles terugkomt, kunnen services die niet automatisch bij het opstarten starten, geplande taken die tijdens de herstart hadden moeten draaien en gekoppelde volumes in een slechte staat achterblijven. Alarmeer op elke reboot buiten een onderhoudsvenster, op waarschuwingsniveau als de server zichzelf heeft hersteld.
Startwaarden
De waarden hieronder zijn voorbeelden van startpunten voor een gemiddelde web- of applicatieserver. Gebruik ze de eerste paar weken en stem ze daarna af op wat je ziet.
MetricWaarschuwing (voorbeeld)Kritiek (voorbeeld)CPUBoven 85% gedurende 15 minutenBoven 95% gedurende 15 minuten, met oplopende responstijdenLoad average (15 min)Boven 1 per coreBoven 2 per coreBeschikbaar geheugenOnder 15%Onder 5%SwapElk gebruik op een server die normaal geen swap gebruiktMeer dan 50% van de swap in gebruikSchijfBoven 80%, of binnen een week vol bij het huidige tempoBoven 90%, of binnen een dag volNetwerkVer buiten het normale bereik voor dat tijdstipDicht bij de capaciteit van de verbinding, of bijna nul op een drukke serverRebootElke reboot buiten een onderhoudsvensterServices kwamen na een reboot niet terug
Uptimecheck servermonitoring rapporteert elke minuut CPU, geheugen, schijf en netwerk op Linux, macOS en Windows. Je stelt per server drempels in voor CPU, geheugen en schijf, met een duur zoals 5 of 15 minuten, en je krijgt ook een alert bij reboots en wanneer een server stil valt. Zo wordt een machine die niet meer rapporteert nooit aangezien voor een rustige. Waarom deze getallen ertoe doen, lees je in je website draaiende houden met monitoring van de serverstatus.
Let ook op de symptomen
Servermetrics beschrijven oorzaken. Je gebruikers ervaren symptomen: trage pagina’s, foutmeldingen en mislukte taken. Monitor allebei. Een uptimecheck met validatie van de respons vertelt je wanneer de site faalt, en een heartbeat vertelt je wanneer de back-up niet is afgerond. Gaan een symptoomalert en een resourcealert tegelijk af, dan is de oorzaak meestal duidelijk. Gaat alleen de resourcealert af, dan heb je vaak nog tijd om het op te lossen voordat iemand iets merkt.
Daardoor kun je serverdrempels ook met een gerust hart hoger zetten. Wordt de site elke minuut gecontroleerd, dan hoeft een CPU-alert niet degene te zijn die een storing opmerkt. Die kun je afstemmen als vroege waarschuwing in plaats van als laatste redmiddel. Voor websitechecks geldt hetzelfde; zie valse alerts verminderen bij uptime monitoring.
Evalueer drempels na incidenten
Drempels zijn nooit af. Stel na elk incident, en voor onrustige servers eens per maand, deze vragen:
Ging er een alert af voordat gebruikers het merkten? Zo niet, welke metric bewoog als eerste, en had een lagere drempel het opgevangen?
Welke alerts gingen af waar niemand iets mee deed? Verhoog ze, voeg een duur toe of verplaats ze naar een kanaal voor overdag.
Bereikte de alert iemand die kon ingrijpen? Zo niet, pas de routering aan.
Is het normale niveau van de server veranderd na een upgrade, een migratie of meer verkeer?
Schrijf de antwoorden in het incidentrapport, zodat elke wijziging een reden heeft. Het sjabloon voor een incident-postmortem heeft daar een aparte sectie voor.
Samenvatting
Alarmeer op wat een mens nodig heeft, met de urgentie die het echt heeft. Gebruik aanhoudende waarden, load per core, beschikbaar geheugen en swap, schijfniveau en groei, en elke ongeplande reboot. Begin met voorbeeldwaarden, leer het normale niveau van elke server kennen en stel bij na elk incident.
Uptimecheck zet servermonitoring naast uptimechecks, heartbeats en statuspagina’s in één account. Start een gratis proefperiode van 14 dagen, geen creditcard nodig.