La supervision ne commence pas par un outil mais par la question : que voulez-vous savoir avant qu'un client ne s'en aperçoive ? Ces guides mettent en place la mesure avec ce qui est déjà sur la machine : /proc, systemd, df, docker stats, cron. Vous apprenez ce qu'est une bonne alerte et pourquoi « CPU au-dessus de 90 % » n'en est généralement pas une.
Une charge de 8 est calme sur un 16 cœurs et une catastrophe sur un 2 cœurs. La charge compte aussi les processus qui attendent un disque, pas seulement le CPU. Et la valeur à 1 minute est presque toujours du bruit. Ce que signifient vraiment les trois chiffres, comment les normaliser par cœur, comment séparer la pression CPU de la pression I/O avec /proc/pressure, et quel seuil mettre dans une alerte.
Un service qui plante est de retour en quelques secondes avec Restart=on-failure. Un service qui pend, un qui tourne en boucle de redémarrage, ou un qui n'a jamais démarré après un reboot, systemd ne le voit pas tout seul. Voici les réglages en drop-in, le gestionnaire OnFailure qui pousse vers votre téléphone, l'astuce WatchdogSec pour les processus bloqués et le script cron qui comble les trous.
Tout ce que vous pouvez voir vous-même avec docker stats, docker events et un healthcheck dans votre fichier compose — plus le script cron qui signale en cinq minutes un conteneur qui redémarre toutes les 30 secondes. Avec le réglage de logging qui empêche les conteneurs de remplir votre disque.
Quatre mesures qui rendent 90 % des incidents visibles à l'avance, avec uniquement ce qui est livré avec Ubuntu 24.04 ou Debian 12 : sysstat, journalctl, df et un script cron de trente lignes qui pousse vers votre téléphone. Et pourquoi « CPU au-dessus de 90 % » est une mauvaise alerte.