Servermonitoring versus websitemonitoring

Twee teams kunnen allebei zeggen dat ze "hun infrastructuur monitoren" en daarmee totaal verschillende dingen bedoelen. Het ene kijkt naar CPU-grafieken op een dashboard. Het andere krijgt een bericht op het moment dat een klant de afrekenpagina niet kan laden. Beide benaderingen zijn nuttig. Geen van beide vervangt de ander.

Dit artikel legt het praktische verschil uit tussen servermonitoring en websitemonitoring, wanneer je welke nodig hebt en hoe een gezonde opzet beide gebruikt.

Servermonitoring: de machine van binnenuit bekijken

Servermonitoring (vaak host-level of infrastructuurmonitoring genoemd) draait een agent op de machine en rapporteert wat er binnenin gebeurt:

• CPU-gebruik en gemiddelde belasting
• RAM- en swapgebruik
• vrije schijfruimte en I/O
• netwerkdoorvoer
• draaiende processen en services

Omdat de agent direct op de host zit, ziet hij dingen die geen enkele externe controle kan zien. Hij weet dat de schijf voor 95 % vol is voordat de database schrijfacties weigert. Hij weet dat een geheugenlek urenlang oploopt voordat het systeem het proces afsluit. Dit is white-box-monitoring (je hebt volledig zicht op de binnenkant).

De prijs daarvoor: de agent vertelt je alleen iets over de machine waarop hij draait. Is de server in orde, maar gaat er een firewallregel, een DNS-record of een bovenliggende load balancer kapot, dan rapporteert de agent rustig "alles groen" terwijl gebruikers een foutpagina zien.

Websitemonitoring: de dienst van buitenaf bekijken

Websitemonitoring (ook externe, black-box- of synthetische monitoring genoemd) controleert je dienst net zoals een echte bezoeker dat zou doen: van buiten je netwerk, via het publieke internet.

Typische externe controles omvatten:

• HTTP/HTTPS - geeft de pagina 200 en de verwachte inhoud terug
• TCP - is de poort open en accepteert hij verbindingen
• Ping/ICMP - is de host bereikbaar
• SSL-certificaat - is het geldig en verloopt het niet binnenkort
• DNS - wordt de naam correct vertaald

Dit is black-box-monitoring. Je weet niet waarom er iets misging, alleen dat het vanuit het oogpunt van de klant misging. En precies om dat oogpunt gaat het. Het vangt hele klassen storingen op waar een agent op de host blind voor is: verlopen certificaten, een verkeerde DNS-configuratie, CDN-problemen, routing-uitval en complete servercrashes waarbij de agent zelf meevalt.

Naast elkaar

Het zijn geen concurrenten, het zijn lagen

De fout is dit als een of-of-keuze te zien. De sterkste opzetten draaien beide:

1. Externe controles vertellen je snel en vanaf meerdere plekken dat gebruikers geraakt worden.
2. Servermetrieken vertellen je waarom, zodat je de echte oorzaak kunt wegnemen.

Een praktijkvoorbeeld: externe monitoring slaat alarm dat je API time-outs geeft. Je opent de servermetrieken en ziet dat de schijf-I/O op 100 % vastzit omdat een logbestand de partitie heeft gevuld. De externe controle vond het symptoom, de interne agent verklaarde het. Samen maakten ze van een vaag "de site is traag" een helder en oplosbaar incident.

Waar ePulz.io past

ePulz.io is gebouwd rond externe black-box-monitoring, goed gedaan. Controles draaien vanaf drie onafhankelijke EU-sondes en een storing wordt pas gemeld als minstens twee van de drie het eens zijn, zodat een enkele defecte netwerkroute je niet om drie uur 's nachts wakker maakt. Je krijgt 9 monitortypes (HTTP, TCP, ping, SSL, DNS en meer) met intervallen tot 1 minuut, afhankelijk van je plan.

Voor de gevallen waarin je echt een blik naar binnen in je eigen netwerk nodig hebt (een server, NAS, printer of dienst die niet aan het internet is blootgesteld), biedt ePulz.io een LAN-agent. Die draait binnen je netwerk en rapporteert de bereikbaarheid van interne hosts terug naar hetzelfde dashboard, zonder iets aan het publieke internet bloot te stellen. Zo heb je het oog van de klant en de interne blik op een plek.

Een verstandige regel:

• Externe monitoring gebruik je voor alles wat de klant raakt. Altijd.
• Metrieken op serverniveau (via je hostingprovider, een aparte agent of onze LAN-agent voor interne doelen) voeg je toe wanneer je detail over de oorzaak nodig hebt of vroege waarschuwing over resource-limieten wilt.

Hoe je begint

Heb je vandaag nog niets, begin dan met de blik van buiten, want daar geven je klanten om. Stel een HTTP-controle in op het hoofddomein en een SSL-controle op het certificaat. Voeg daarna intern overzicht toe waar dat de moeite waard is.

Wil je meteen controleren of een poort bereikbaar is, nog voor je een monitor instelt. Probeer de gratis poortchecker. Ben je klaar voor permanente dekking, bekijk dan hoe uptime monitoring werkt en onze plannen. De proefperiode van 7 dagen is gratis en vraagt geen creditcard.