Veelgestelde problemen

Uptime monitoring draait niet om het percentage in je dashboard, maar om de vraag of je systeem daadwerkelijk werkt wanneer een gebruiker het aanraakt. Dit artikel legt uit hoe monitoring op verschillende lagen werkt, wat die 99,9% in je SLA écht betekent, en waarom een server die "online" is toch een kapotte website kan zijn.

Vereisten

• Een Linux-server (elke moderne distributie, getest op Ubuntu 24.04 LTS)
• Toegang tot een monitoringtool of de bereidheid om handmatige checks te draaien
• Basiskennis van de commandoregel

Stappen

1. Begrijp wat uptime wérkelijk meet

Uptime is de periode waarin een systeem operationeel en beschikbaar is voor gebruikers. Downtime is het tegenovergestelde: de tijd dat het systeem offline is of niet functioneert zoals verwacht. Zo simpel is de definitie. De praktijk is weerbarstiger, want "beschikbaar" laat ruimte voor interpretatie.

Een server die ping-verzoeken beantwoordt maar waarvan de webserver is gecrasht, is technisch "online". Voor een bezoeker die een foutmelding ziet, is de website gewoon down. Het verschil tussen die twee werelden bepaalt of je monitoring iets waard is.

2. Meet op de juiste laag van de netwerkstack

De controle gebeurt op vaste intervallen, meestal elke 30 seconden tot 5 minuten. Die frequentie is een afweging: te vaak controleren belast het systeem, te weinig controleren vertraagt de detectie van uitval. De methode bepaalt welke laag je test:

• Ping (ICMP) controleert of het systeem überhaupt reageert op netwerkniveau
• TCP-verbinding test of een specifieke poort open is
• HTTP-verzoek controleert of de website daadwerkelijk inhoud retourneert

Een ping die slaagt zegt weinig over een database die vastloopt. Een HTTP-check die een 200-status ontvangt zegt niets over een trage query die de pagina na 30 seconden pas oplevert. Hoe meer lagen je test, hoe beter je beeld — maar hoe meer ruis je ook krijgt.

3. Bereken wat een uptime-percentage werkelijk betekent

Het percentage bereken je door de totale online tijd te delen door de totale tijd in een periode. De cijfers liegen niet, maar ze verbergen wel veel:

• 99% — ongeveer 7 uur downtime per maand
• 99,9% — maximaal 43 minuten en 50 seconden downtime per maand
• 99,99% — minder dan 5 minuten downtime per maand
• 99,999% ("five nines") — minder dan 26 seconden downtime per maand

Voor een kleine blog is 99% prima. Voor een betaalplatform is 99,9% al een nachtmerrie. De hogere percentages vereisen redundante systemen, meerdere datacenters en geavanceerde failover-mechanismen. Die infrastructuur kost geld en complexiteit. Vraag je eerst af wat een uur downtime jouw organisatie kost, en reken dan pas terug naar het percentage dat je nodig hebt.

4. Controleer of je systeem correct functioneert, niet alleen of het reageert

Een HTTP-verzoek dat een 200-status retourneert, zegt alleen dat de webserver draait. Of de pagina daadwerkelijk laadt, of een gebruiker kan inloggen, of een bestelling kan worden afgerond — dat weet je pas als je het test. Dit heet functional monitoring of synthetic monitoring: je bootst een realistische gebruikersactie na.

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://jouwdomein.nl/login

Dit commando geeft je de HTTP-statuscode en de totale responstijd. Een 200 die er 28 seconden over doet, is functioneel gezien een storing. De server is online, de website is kapot.

5. Stel meldingen in die je daadwerkelijk wakker maken

Wanneer een monitor uitval detecteert, volgt een melding. E-mail, sms, Slack of Microsoft Teams — de kanalen verschillen, het principe blijft: een beheerder moet op de hoogte zijn, ook buiten kantoortijden.

Stel escalatieprocedures in. Reageert de eerste contactpersoon niet binnen een bepaalde tijd, stuur de melding dan door naar een tweede of derde verantwoordelijke. Een melding die niemand leest is geen monitoring, het is een logbestand met extra stappen.

6. Analyseer de oorzaak van downtime, niet alleen het feit

Uitval ontstaat door hardwarefouten, netwerkproblemen, softwarebugs, beveiligingsaanvallen of menselijke fouten. Het verschil maakt uit voor de oplossing. Logbestanden en monitoringdata vertellen je wat er gebeurde; de analyse vertelt je hoe je het voorkomt.

iostat -x 5 3

Dit commando rapporteert CPU- en schijfgebruik over drie intervallen van vijf seconden. Staat de schijf op 100% utilisation, dan weet je waar je moet zoeken. Combineer dit met `top` voor een real-time overzicht van processen die CPU of geheugen verbruiken.

top -b -n 1 | head -20

De output toont de twintig zwaarste processen. Een proces dat structureel boven de 90% CPU zit, is vaak de boosdoener — of een signaal dat je capaciteit moet uitbreiden.

7. Kies de juiste tool voor je omgeving

Voor systemen die continu moeten draaien, bestaat de LMA-stack (Logging, Monitoring, and Alerting). Deze verzamelt logs, meet prestaties en stuurt meldingen bij afwijkingen. De stack werkt nog, maar wordt op termijn opgevolgd door de Canonical Observability Stack (COS), een modernere oplossing voor monitoring en observability. Voor omgevingen met beperkte middelen bestaat COS Lite, een lichtere variant.

De keuze tussen LMA en COS bepaal je door te kijken naar je bestaande infrastructuur. Draai je al op Ubuntu en wil je Canonical-ondersteuning, dan is COS de logische stap. Heb je een gemengde omgeving met meerdere leveranciers, dan blijft de klassieke stack langer bruikbaar. Beide doen hetzelfde: logs verzamelen, metrieken meten, meldingen sturen. Het verschil zit in de integratie met de rest van je systeem.

Voor wie geen volledige observability-stack wil opzetten, bestaan lichtere alternatieven. `tmux` is een terminal multiplexer die meerdere terminals in één scherm beheert en sessies kan detachen en later weer koppelen. `byobu` is een wrapper rondom tmux of screen die extra systeeminformatie toont in een statusbalk onderaan het scherm. Mission Center biedt een grafische interface voor CPU, geheugen, schijf, netwerk en GPU-gebruik, per applicatie en proces.

TuneD is een Linux-service die het systeem dynamisch optimaliseert op basis van het type workload. Geen directe monitor, maar wel relevant: een systeem dat is afgestemd op zijn belasting valt minder vaak uit.

Verificatie

Controleer of je monitoring daadwerkelijk werkt door een test uit te voeren:

systemctl stop nginx && sleep 60 && systemctl start nginx

Stopt je webserver, dan moet je binnen de ingestelde interval een melding ontvangen. Ontvang je die niet, dan werkt je monitoring niet — of staat de check op de verkeerde laag. Na de test controleer je of de service weer draait:

systemctl status nginx --no-pager

Veelgestelde problemen

Mijn dashboard zegt 99,9% uptime, maar gebruikers klagen over trage laadtijden. Uptime-percentages meten beschikbaarheid, niet prestaties. Een server die traag maar consistent antwoordt, scoort 100% uptime. Voeg synthetic monitoring toe die een volledige gebruikersactie nabootst, inclusief responstijd, om prestatieproblemen te detecteren.

Ik krijg meldingen voor uitval die er niet is. Dit is vaak een netwerkprobleem: je monitoringserver zit in een ander netwerk en een firewall blokkeert de check. Test of de check handmatig werkt vanaf dezelfde locatie als je monitoringserver. Soms is een time-out te krap ingesteld — verhoog de drempelwaarde voordat je de infrastructuur aanpast.

Mijn provider meldt 100% uptime, maar mijn website was onbereikbaar. Providers hanteren verschillende definities van "bereikbaar". De een meet alleen of de server pingt, de ander of de webserver een 200-status retourneert. Vraag je provider welke laag ze meten en vergelijk dat met je eigen checks. Het verschil tussen die twee is de informatie die je nodig hebt.