Monitoring begint niet met een tool maar met de vraag wat je wilt weten vóór een klant het merkt. Deze how-to's zetten meting op met wat er standaard op de machine staat: /proc, systemd, df, docker stats, cron. Je leert wat een goede alert is en waarom "CPU boven 90 %" dat meestal niet is.
Load 8 is rustig op een 16-core en een ramp op een 2-core. Load telt ook processen die op een schijf wachten, niet alleen CPU. En de 1-minuut-waarde is bijna altijd ruis. Wat de drie getallen echt betekenen, hoe je ze normaliseert per core, hoe je CPU-druk van I/O-druk onderscheidt met /proc/pressure, en welke drempel je in een alert zet.
Een service die crasht is met Restart=on-failure in seconden terug. Een service die hangt, een die in een restart-loop zit, of een die na een reboot nooit is gestart, ziet systemd niet vanzelf. Dit zijn de drop-in-instellingen, de OnFailure-handler die naar je telefoon pusht, de WatchdogSec-truc voor hangende processen en het cron-script dat de gaten dicht.
Alles wat je met docker stats, docker events en een healthcheck in je compose-file zelf kunt zien — en het cron-script dat een container die elke 30 seconden herstart binnen vijf minuten meldt. Inclusief de logging-instelling die voorkomt dat containers je schijf volschrijven.
Vier metingen die 90 % van de incidenten vooraf zichtbaar maken, met alleen wat er standaard op een Ubuntu 24.04- of Debian 12-server staat: sysstat, journalctl, df en een cron-script van dertig regels dat naar je telefoon pusht. Plus waarom "CPU boven 90 %" een slechte alert is.