On ne gère bien que ce que l'on mesure
« Le serveur était lent hier » n'est pas actionnable. « Le load average a dépassé 8 entre 14 h et 14 h 20 avec 92 % d'I/O wait » l'est. Le monitoring transforme les anecdotes en données.
Netdata : zéro configuration, tout de suite
bash <(curl -Ss https://my-netdata.io/kickstart.sh) et vous avez des milliers de métriques en temps réel : CPU par cœur, IOPS par disque, latence disque, connexions réseau. Exposez-le sur localhost derrière un reverse proxy authentifié, jamais en public.
Les quatre métriques vitales
Load average vs vCore : au-dessus du nombre de vCores en continu, il faut plus de CPU. I/O wait : au-dessus de 10 %, le stockage est le goulot (pas chez nous, mais ailleurs…). RAM disponible : si le swap travaille, ajoutez de la mémoire. Conntrack/connexions : les pics soudains signalent souvent un scraping ou une attaque naissante.
Les alertes, pas les dashboards
Un beau dashboard que personne ne regarde ne sert à rien. Configurez des alertes (Netdata → Discord/Slack/e-mail) sur les quatre métriques vitales avec des seuils stricts, et n'ouvrez les dashboards que pour investiguer.
Uptime externe
Le monitoring interne ne voit pas sa propre mort. Ajoutez un sondeur externe (Uptime Kuma auto-hébergé sur un autre VPS, ou un service tiers) qui vérifie vos endpoints HTTP toutes les 30 secondes depuis l'extérieur.