Uptime monitoring voor resellers (zonder onnodige serverbelasting)

Uptime monitoring is belangrijk om snel te merken wanneer een server of website tijdelijk niet bereikbaar is. Tegelijkertijd kan te agressieve monitoring juist problemen veroorzaken. Als je tientallen websites elke minuut en vaak ook nog gelijktijdig laat controleren, kan dit voor de server lijken op onnatuurlijk verkeer. Dit kan de performance van alle websites op die server negatief beïnvloeden en vormt daarmee ook een risico voor de algehele bereikbaarheid en uptime.

In deze handleiding leggen we uit hoe je als reseller betrouwbaar kunt monitoren, terwijl je de serverload beperkt.

Waarom "alles elke minuut" monitoren onverstandig is

Elke monitorcheck is een echte website hit. Als je 50 websites elke minuut checkt, creëer je een continue stroom aan requests die:

• vaak PHP processen opstart (bij dynamische pagina's),
• database en cache lagen raakt,
• en bij pieken tegelijk kan zorgen voor wachtrijen/503’s.

In het kort gaat je monitoring dan lijken op load test/DDoS achtig verkeer. Dat is niet "normaal" gebruikersgedrag.

De aanbevolen aanpak

We doen dit in twee lagen:

Laag 1: op serverbasis (je reseller pakket)

Doel: snel weten of de server als geheel bereikbaar is, zonder tientallen checks.

• Monitor url: https://s1139.hostingsecure.com:2087/
• Interval: 60 seconden (1 minuut)
• Type check: HTTP(S) check op een statische pagina (geen WordPress, geen PHP)

Hiermee zie je snel of de webserver/HTTPS bereikbaar is, terwijl je de server minimaal (statisch bestand) belast.

Laag 2: per website: sanity checks (minder frequent)

Doel: controleren of (een selectie van) klantwebsites functioneel online zijn.

• Monitor url: https://www.websitenaam.nl/uptime.txt (zie onderstaand de uitleg)
• Interval: elke 30–60 minuten
• Probeer checks te spreiden (niet alles op exact dezelfde minuut starten)

Tip: Voor veel resellers is het voldoende om niet 100% van alle sites continu te checken, maar een slimme selectie + server level monitor. Je kunt er bijvoorbeeld wel voor kiezen om kritische websites voor een korte periode (bijvoorbeeld twee weken) apart op te nemen in de monitoring als tijdelijke monitor.

Toelichting voor het maken van een lightweight monitor pagina

Maak op elke server waar je een WHM op hebt een simpel endpoint aan dat je wilt monitoren. Hiermee check je alles op een minimale impact bestand, wat de monitoring zeer licht houd en niet alles non stop in de server cache zet. Als je op grotere schaal wilt monitoren is dit de aanbevolen opzet.

1. Maak een (sub)domein aan, bijvoorbeeld: uptime.jouwresellerdomein.nl (op dezelfde server als je klantaccounts)
2. Plaats in de root een bestand, bijvoorbeeld uptime.txt, met inhoud: OK of iets anders wat je wilt gebruiken om te monitoren.

3. Laat je monitoringtool controleren op:

   URL: https://uptime.jouwresellerdomein.nl/uptime.txt

   Keyword: OK (of indien je iets anders hebt ingesteld)

   Interval: 60s

Belangrijk: Houd dit endpoint statisch (geen PHP, geen extra belasting op de server). Hiermee zorg je dat je geen homepage of andere zware pagina als 1 minuut monitor aan hoeft te houden.

Welke URL monitor je op WordPress sites (zonder caching-issues)?

Als je echt op website niveau monitort (laag 2), kies dan bij WordPress bij voorkeur: https://jouwdomein.nl/wp-login.php

Waarom:

Deze pagina is niet gecached en is lichtgewicht, waardoor issues sneller en betrouwbaarder zichtbaar worden.

Voorkom monitoring pieken (de grootste valkuil)

Veel monitoringtools checken vanaf meerdere locaties tegelijk, zowel HTTP als HTTPS parallel, en starten veel monitors exact op dezelfde seconden/minuut. Dat kan piekbelasting geven.  

Best practices

• Gebruik één monitor per endpoint (niet meerdere tools/instanties tegelijk).
• Vermijd dubbele checks (bijv. niet zowel HTTP als HTTPS als dat niet nodig is).
• Gebruik bij voorkeur 1–2 locaties i.p.v. wereldwijd overal tegelijk.
• Spreid checks (zodat niet alles om :00 start, maar op verschillende tijdstippen: :01, :03, :05 etc).

Statuspagina: check eerst of er onderhoud/incident is

Als je een alert krijgt, check altijd eerst de Hoasted statuspagina. Indien wij onderhoud plegen aan het netwerk of de server, dan vermelden wij dit altijd op onze statuspagina.

Zie daarvoor: https://status.hoasted.com

Als monitoring toch te zwaar wordt

Als monitoring te vaak of tegelijk draait, kan LiteSpeed het monitor-IP afremmen of tijdelijk blokkeren. Dit kan leiden tot false down meldingen terwijl de website nog werkt. Hieronder zie je hoe LiteSpeed dit afhandelt zodra de requestlimiet wordt overschreden.

Request 1–8: Direct verwerkt (binnen de toegestane limiet)

Dit zijn dynamische (PHP) requests vanaf één IP adres die binnen de door LiteSpeed ingestelde grens vallen. Deze requests worden zonder vertraging afgehandeld.

Request 9–12: In wachtrij / afgeremd

Zodra meer dan 8 dynamische requests per seconde vanaf hetzelfde IP worden gedaan, beschouwt LiteSpeed dit als te veel gelijktijdige belasting en begint het verkeer af te remmen.

Detectie door LiteSpeed (wat doet dit precies?)

LiteSpeed detecteert: “IP exceeded 8 dynReqPerSec”

Hierdoor wordt direct een grace period van 15 seconden gestart.

De status van het IP adres verandert naar “throttled” (afgeremd).

Gedrag tijdens de grace period

Requests 9–12: Worden zeer langzaam verwerkt

Nieuwe requests vanaf dit IP: Worden sterk vertraagd

Bestaande verbindingen: Mogen normaal afronden

Na afloop van de grace period (15 seconden)

Als het aantal requests normaliseert:

• De throttling wordt opgeheven
• Er wordt geen blokkade toegepast
• Alle volgende requests worden weer op normale snelheid verwerkt

Wat gebeurt er bij aanhoudend verkeer? (ban situatie)

Wanneer het IP-adres tijdens de grace period alsnog meerdere extra PHP requests blijft sturen (bijvoorbeeld door gelijktijdige monitoringchecks), ziet LiteSpeed dit als agressief gedrag.

Voorbeeld:

Op seconde 5 worden nog 5 extra PHP requests uitgevoerd.

Resultaat:

Onmiddellijke tijdelijke blokkade van 300 seconden (5 minuten)

Tijdens deze periode worden alle requests vanaf dit IP geweigerd.

Belangrijke conclusie voor monitoring

Te agressieve of gelijktijdige monitoring (zoals meerdere WordPress/WooCommerce pagina’s tegelijk checken vanaf één IP) kan hierdoor leiden tot false “down” meldingen, terwijl de website zelf correct functioneert.

Kort samengevat

1. LiteSpeed staat per IP adres maximaal 8 dynamische (PHP) requests per seconde toe.
2. Wordt deze limiet overschreden, dan worden extra requests afgeremd (throttled).
3. Blijft het IP daarna alsnog te veel requests versturen, dan volgt automatisch een tijdelijke blokkade van 5 minuten. Deze blokkade wordt automatisch opgeheven.