Je server bewaken

Module 8: Back-ups en bewaking · Leestijd: 10 minuten

Leerdoel: Na deze les kun je bepalen wat je van je server bewaakt (van buiten en van binnen), welke drempels zinvol zijn, en hoe je zorgt dat een melding je echt bereikt zonder dat je in meldingen verdrinkt.

Kernbegrippen: bewaking van buitenaf, bewaking van binnen, uptime, http-controle, poortcontrole, certificaatverloop, schijfruimte, geheugen, load, heartbeat (dead man's switch), drempel, meldkanaal, alarmmoeheid, grafieken van de aanbieder

Waarom bewaken?

Zonder bewaking hoor je van problemen via je klanten, of helemaal niet. Een website die sinds zaterdag plat ligt, een certificaat dat verliep, een schijf die volliep, een back-up die al drie weken stil mislukt: allemaal dingen die je op tijd had kunnen zien. Bewaking betekent: een programma kijkt continu, en waarschuwt jou als iets niet klopt.

Een goede bewaking beantwoordt twee vragen:

1. Werkt het voor de gebruiker? Dat meet je van buitenaf.
2. Gaat het binnenkort mis? Dat meet je van binnen: schijf, geheugen, updates, back-ups.

Van buitenaf: wat de gebruiker ziet

Bewaking van buitenaf draait op een andere machine dan je server, het liefst bij een andere aanbieder. Logisch: als je server plat ligt, kan hij zelf niet meer waarschuwen.

Het certificaat verdient extra aandacht. Let's Encrypt-certificaten zijn kort geldig en worden automatisch vernieuwd (les 7.3), maar als dat vernieuwen stil mislukt, merk je het pas als bezoekers een waarschuwing krijgen. Let's Encrypt zelf stuurt sinds juni 2025 geen herinneringsmails meer over verlopende certificaten, en raadt zelf bewaking aan. Een certificaatcontrole die waarschuwt bij minder dan 14 dagen geldigheid is dus geen luxe.

Een gangbaar programma om dit zelf te doen is Uptime Kuma, dat je in les 9.4 in een container installeert. Zet het dan bij voorkeur niet op dezelfde server die het moet bewaken, of combineer het met een tweede, externe controle. Er zijn ook diensten van derden die hetzelfde doen; kies er een die bij je past, en let erop waar ze gevestigd zijn als er gegevens van je klanten in meldingen kunnen staan.

Van binnen: wat er binnenkort misgaat

Sommige problemen zie je van buiten pas als het te laat is. Die meet je op de server zelf:

Dit kan met een eenvoudig script en een timer (les 6.3) dat bij een overschrijding een melding stuurt, of met een bewakingsprogramma met een agent op de server (bekende open-source voorbeelden zijn Netdata en de combinatie Prometheus met node_exporter). Begin klein: schijf, mislukte diensten en back-ups vangen de meeste problemen.

De grafieken in het paneel van je aanbieder (processor, geheugen, netwerk, schijf over een dag tot een jaar) zijn een prima aanvulling om trends te zien: groeit je schijf elke maand een paar procent, dan weet je wanneer hij vol is. Bij WebOké staan die in het VPS-scherm; bij andere aanbieders vergelijkbaar. Ze sturen meestal geen melding, dus ze vervangen bewaking niet.

De heartbeat: melden als er níets gebeurt

Sommige dingen moet je juist bewaken op het uitblijven van een signaal. De back-up van vannacht is het beste voorbeeld: als het script niet eens start (timer uit, server uit, script kapot), komt er ook geen foutmelding.

De oplossing heet een heartbeat of dead man's switch: je bewaking verwacht elke dag een seintje. Het back-upscript stuurt aan het eind, alleen als alles gelukt is, een kleine http-aanvraag naar een vaste, geheime URL van je bewaking:

restic backup ... && restic check && curl -fsS -m 10 https://status.example.com/api/push/Xyz123abc?status=up >/dev/null

Komt het seintje een dag niet, dan krijg je een melding. Uptime Kuma heeft daarvoor het monitortype Push; er zijn ook zelf te hosten programma's als Healthchecks. Zo bewaak je met één regel of je back-up echt liep.

Meldingen die aankomen, en niet te veel

Een melding die niemand leest, is geen bewaking. Regel drie dingen:

1. Een meldkanaal dat je echt ziet: een pushbericht op je telefoon, een chatkanaal, sms. Mail kan, maar alleen als je server betrouwbaar mail kan versturen, en mail wordt makkelijk over het hoofd gezien. Gebruik voor de belangrijkste meldingen twee kanalen.
2. Niet afhankelijk van wat je bewaakt. Stuurt je server zelf de mail over een volle schijf, dan komt die niet als de schijf vol is. Bewaking van buitenaf en een heartbeat vangen dat op.
3. Weinig, maar terecht. Krijg je elke dag tien meldingen waar je niets mee doet, dan ga je ze negeren, ook de ene die ertoe doet. Dat heet alarmmoeheid. Stel drempels zo dat een melding betekent: je moet iets doen. Laat een melding pas afgaan na een paar mislukte controles achter elkaar (bijvoorbeeld drie keer), zodat één verloren pakketje je niet wakker maakt.

Test je meldingen: zet een dienst even uit en kijk of de melding komt, en hoe lang het duurde.

Wat je niet moet doen

• Bewakingspagina's open voor iedereen met interne namen en adressen. Een openbare statuspagina mag, maar laat alleen zien wat bezoekers mogen weten.
• Een beheerdersaccount van je bewaking zonder sterk wachtwoord en 2FA. Wie in je bewaking zit, kan meldingen uitzetten.
• Agents met meer rechten dan nodig. Een bewakingsagent hoeft meestal geen root te zijn.

Samenvatting

• Bewaak van buitenaf of het werkt (http, poort, certificaat, DNS), vanaf een andere machine, en van binnen of het binnenkort misgaat (schijf, geheugen, diensten, updates, back-ups).
• Certificaten verdienen een eigen controle: Let's Encrypt stuurt sinds juni 2025 geen herinneringsmails meer.
• Een heartbeat meldt het uitblijven van een seintje; ideaal voor back-ups en geplande taken.
• Kies een meldkanaal dat je echt ziet, onafhankelijk van de server zelf, en stel drempels zo dat elke melding actie vraagt.
• De grafieken van je aanbieder tonen trends, maar sturen meestal geen melding.

Quiz

Opdracht

Opdracht O8.3: Je bewakingslijst. Maak voor je eigen server een bewakingslijst: welke controles van buitenaf (met welk interval en vanaf waar), welke van binnen (met drempels), welke heartbeat(s), en via welk kanaal de meldingen komen. Richt minstens één externe http- of certificaatcontrole en één heartbeat in (bijvoorbeeld voor je back-up) en test de melding door een dienst even uit te zetten. Noteer hoe lang het duurde voor de melding kwam.

Verder lezen

• Geen toegang meer tot je VPS: wat nu?
• Let's Encrypt, Expiration Notification Service Has Ended: https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
• Uptime Kuma (GitHub): https://github.com/louislam/uptime-kuma