Server-uptime monitoren: checks, tools en alerts

Om server-uptime te monitoren voert u geautomatiseerde checks uit van buiten de server (ping, TCP-poort of HTTP-requests vanaf meerdere locaties), verzamelt u de eigen health-signalen van de server met een agent, en alarmeert u alleen wanneer meerdere locaties achter elkaar falen. Registreer daarna elke storing, zodat u elke maand de beschikbaarheid kunt berekenen ten opzichte van uw SLA.

Belangrijkste punten

• Externe synthetische checks beantwoorden "kunnen gebruikers erbij?"; interne agents beantwoorden "waarom ligt het plat?". U hebt beide nodig.
• Controleer vanaf minstens drie locaties en alarmeer bij opeenvolgende fouten, om valse alarmen van één slecht netwerkpad te voorkomen. Microsoft adviseert minstens vijf testlocaties voor beschikbaarheidstests in Azure.
• Test wat gebruikers gebruiken: een HTTPS-request dat statuscode en pagina-inhoud controleert is beter dan een ping.
• Met 99,9% beschikbaarheid is nog steeds ongeveer 43,8 minuten downtime per maand toegestaan. Weet wat uw doel toestaat voordat u alertdrempels instelt.
• Sluit afgesproken onderhoudsvensters consistent uit en rapporteer uptime elke maand uit dezelfde data.

Wat is monitoring van server-uptime?

Monitoring van server-uptime is het continu controleren of een server en de services erop bereikbaar zijn en correct reageren. Het levert twee dingen op: alerts wanneer iets uitvalt, en een historie die u kunt omzetten in een beschikbaarheidspercentage.

Uptime en beschikbaarheid zijn verwant, maar niet identiek. Een server kan aanstaan (hoge uptime) terwijl de webservice fouten teruggeeft (lage beschikbaarheid). Voor de meeste bedrijven telt de beschikbaarheid van de service zoals gebruikers die ervaren.

Hoeveel downtime staat elk uptimedoel toe?

Beschikbaarheid is (totale tijd − downtime) ÷ totale tijd. De tabel rekent gangbare doelen om naar toegestane downtime, uitgaande van een gemiddelde maand van 730 uur.

Een strak doel verandert hoe u monitort. Bij 99,99% kan een check-interval van vijf minuten niet eens elke overschrijding detecteren, dus hebt u checks nodig elke minuut of sneller en een on-call-reactie die in minuten wordt gemeten. Het hoofdstuk embracing risk uit Google's SRE-boek legt uit waarom elke extra negen meer kost en waarom het doel de bedrijfsbehoefte moet volgen.

Welke checks voert u uit?

Externe (synthetische) checks

• ICMP-ping: laat zien dat de host op het netwerk reageert. Goedkoop, maar veel firewalls blokkeren het, en een host kan op ping antwoorden terwijl de applicaties uit de lucht zijn.
• TCP-poortchecks: bevestigen dat een service luistert, bijvoorbeeld 443 voor HTTPS, 3389 voor RDP of 5432 voor PostgreSQL.
• HTTP(S)-checks: vragen een URL op en controleren de statuscode, responstijd en een stuk verwachte inhoud. Gebruik een eigen health-endpoint dat ook de databaseverbinding test.
• TLS-certificaatchecks: waarschuwen voordat een certificaat verloopt. Een verlopen certificaat is voor gebruikers een storing, ook als de server gezond is.
• DNS-checks: bevestigen dat de naam naar het juiste adres verwijst.

Interne (agent-gebaseerde) signalen

• Heartbeat: de agent meldt zich elke minuut; een ontbrekende heartbeat betekent dat de host of agent uitgevallen is.
• Uptimeteller van het systeem: toont ongeplande herstarts. Gebruik op Linux uptime of last reboot; op Windows registreert event-ID 6008 in het systeemlogboek een onverwachte afsluiting.
• Resourcemetrics: CPU, geheugen, schijfruimte en schijflatentie. Volle schijven en uitgeput geheugen zijn veelvoorkomende oorzaken van "wel aan, maar werkt niet".
• Status van services en processen: draait de webserver, database of geplande taak?

Voor Windows-hosts staat in onze gids over hoe u Windows Server-prestaties monitort welke tellers u het best verzamelt.

Welke tools kunnen server-uptime monitoren?

De keuze is minder belangrijk dan de inrichting. Ook een zelf gehoste tool moet worden bewaakt: staat uw enige monitoringserver in hetzelfde rack als de servers die hij bewaakt, dan neemt een stroomstoring beide mee. Draai minstens één externe check vanaf een ander netwerk of een cloudservice.

Uptime-alerts instellen zonder valse alarmen

1. Gebruik meerdere locaties. Microsoft adviseert minstens vijf testlocaties voor beschikbaarheidstests in Azure en een alertdrempel van het aantal locaties min twee, bijvoorbeeld drie falende van de vijf.
2. Eis opeenvolgende fouten. De retry-optie van Azure meldt een fout pas nadat drie opeenvolgende pogingen mislukken; Microsoft merkt op dat ongeveer 80% van de fouten bij een nieuwe poging verdwijnt.
3. Bepaal de ernst op basis van de impact. Een klantenportaal in productie pagineert de on-call-engineer; een testserver stuurt een ticket.
4. Stuur alerts naar mensen die kunnen handelen, met escalatie als niemand binnen een afgesproken tijd bevestigt.
5. Zet gepland onderhoud stil in de monitoringtool in plaats van alerts uit gewoonte te negeren.
6. Alarmeer ook bij herstel, zodat het team weet wanneer het incident voorbij is.

De richtlijn van Google's SRE over het monitoren van gedistribueerde systemen voegt een nuttige regel toe: elke pagina moet urgent en uitvoerbaar zijn en een mens vereisen. Al het andere hoort in een ticket of op een dashboard.

Uptime rapporteren ten opzichte van een SLA

• Definieer wat als down telt, bijvoorbeeld "health-endpoint faalt vanaf drie van de vijf locaties bij twee opeenvolgende checks".
• Spreek af welke onderhoudsvensters worden uitgesloten en leg ze vast in de tool.
• Bereken de maandelijkse beschikbaarheid uit check-resultaten, niet uit het hoofd of uit ticketnotities.
• Houd een storingslog bij met start, einde, oorzaak en oplossing. Patronen, zoals storingen na elke patchnacht, laten zien waar u moet investeren.
• Vergelijk uw cijfer met wat uw cloudprovider toezegt. De Amazon Compute SLA zegt bijvoorbeeld 99,99% maandelijkse uptime toe voor EC2 dat over meerdere availability zones in een regio is uitgerold, maar slechts 99,5% voor één EC2-instance. De beschikbaarheid van uw applicatie kan nooit hoger zijn dan wat de zwakste afhankelijkheid levert.

Monitoring vertelt u over storingen; redundantie voorkomt ze. Draai kritieke workloads op meer dan één server of availability zone achter een load balancer, zodat één uitval de service niet platlegt. WorkBuster, een SaaS-platform voor werving, draait op EC2 achter een Application Load Balancer met multi-AZ MySQL RDS, een auto-scaling group en CloudWatch-dashboards en -alarmen; de casus WorkBuster toont de volledige opzet.

Hoe Opsio helpt

Opsio verzorgt 24/7-monitoring en incidentafhandeling voor servers en cloudworkloads op AWS, Azure en Google Cloud. Wij richten checks, alertroutering en maandelijkse beschikbaarheidsrapporten in, en onze engineers handelen de alerts af. Zie onze pagina's over cloudmonitoring en -support, monitoring van infrastructuur op afstand en observability met Prometheus en Grafana.

Veelgestelde vragen

Hoe controleer ik hoe lang een server al draait?

Voer op Linux uptime of last reboot uit. Open op Windows het tabblad Prestaties van Taakbeheer, voer systeminfo uit en lees "System Boot Time", of bekijk het systeemlogboek. Deze tonen de tijd sinds de laatste herstart, niet of services beschikbaar waren.

Hoe vaak moeten uptimechecks draaien?

Voor de meeste productieservices elke een tot vijf minuten. Stem het interval af op uw doel: bij 99,99% hebt u maar ongeveer 4,4 minuten downtime per maand, dus een interval van vijf minuten is te traag om dat te meten.

Is ping genoeg om server-uptime te monitoren?

Nee. Ping bewijst alleen dat de netwerkstack reageert. Voeg een TCP- of HTTPS-check toe op de service waar gebruikers van afhankelijk zijn, bij voorkeur met een controle op inhoud, plus agent-gebaseerde checks op de server zelf.

Wat is een goed uptimepercentage voor een server?

Voor bedrijfsapplicaties is 99,9% een gangbaar doel; services voor klanten mikken vaak op 99,95% of hoger. Hogere doelen vragen redundantie: AWS zegt bijvoorbeeld slechts 99,5% toe voor één EC2-instance, maar 99,99% voor EC2 verspreid over availability zones.

Kan ik uptime gratis monitoren?

Ja. Open-sourcetools zoals Prometheus met blackbox_exporter, Zabbix of Nagios kosten niets aan licenties, al betaalt u in hosting en onderhoudstijd. De native checks van cloudproviders zijn goedkoop voor een klein aantal endpoints.

Gerelateerde artikelen

• Wat is cloudmonitoring?
• Wat is realtimemonitoring voor servers en applicaties?
• Windows Server-prestaties monitoren: tools en metrics