Veelvoorkomende problemen

Uptimemonitoring draait niet om het percentage in uw dashboard, maar om de vraag of uw systeem daadwerkelijk werkt wanneer een gebruiker het aanraakt. Dit artikel legt uit hoe monitoring op verschillende lagen werkt, wat die 99,9% in uw 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 uit te voeren
• 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 uw 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 u 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 u test, hoe beter uw beeld — maar hoe meer ruis u ook krijgt.

3. Bereken wat een uptime-percentage werkelijk betekent

Het percentage berekent u 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 u eerst af wat een uur downtime uw organisatie kost, en reken dan pas terug naar het percentage dat u nodig hebt.

4. Controleer of uw 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 u pas als u het test. Dit heet functionele monitoring of synthetische monitoring: u bootst een realistische gebruikersactie na.

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

Dit commando geeft u 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 u 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 de kantooruren.

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 u wat er gebeurde; de analyse vertelt u hoe u het voorkomt.

iostat -x 5 3

Dit commando rapporteert CPU- en schijfgebruik over drie intervallen van vijf seconden. Staat de schijf op 100% utilisatie, dan weet u waar u 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 u uw capaciteit moet uitbreiden.

7. Kies de juiste tool voor uw 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 bepaalt u door te kijken naar uw bestaande infrastructuur. Draait u al op Ubuntu en wilt u Canonical-ondersteuning, dan is COS de logische stap. Hebt u 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 uw 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 uw monitoring daadwerkelijk werkt door een test uit te voeren:

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

Stopt uw webserver, dan moet u binnen de ingestelde interval een melding ontvangen. Ontvangt u die niet, dan werkt uw monitoring niet — of staat de check op de verkeerde laag. Na de test controleert u 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: uw monitoringserver zit in een ander netwerk en een firewall blokkeert de check. Test of de check handmatig werkt vanaf dezelfde locatie als uw monitoringserver. Soms is een time-out te krap ingesteld — verhoog de drempelwaarde voordat u de infrastructuur aanpast.

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