Partie 14 — Observer & superviser

⏱️ TL;DR — Ton app tourne, elle est déployée, sécurisée, en HTTPS. Mais le sais-tu vraiment ? Une prod qu’on ne regarde pas est une prod qui tombe sans prévenir — et c’est un client mécontent qui t’apprend la panne, des heures trop tard. Cette partie te donne les yeux : lire les logs (la boîte noire de ta machine), mesurer les métriques système (CPU, RAM, disque : qui sature ?), passer du contrôle ponctuel à un monitoring continu avec alertes (être prévenu quand le disque dépasse 85% ou qu’un cert expire), et enfin surveiller l’application elle-même (erreurs, temps de réponse, healthcheck). Le principe qui traverse tout : on ne pilote que ce qu’on mesure, et on veut être prévenu avant l’utilisateur.

Le problème qu’on résout

Tu as fait le plus dur. Le VPS est provisionné, durci, ton app tourne en service derrière Nginx en HTTPS, la base est sauvegardée, le déploiement est automatisé. Tout est vert. Le jour de la mise en ligne, tout va bien.

Puis la vie de la prod commence, et elle est silencieuse. Le disque se remplit de logs, semaine après semaine, sans un bruit. Un pic de trafic sature la RAM une nuit, l’OOM killer tue ton process, systemd le relance, personne ne le sait. Le certificat HTTPS arrive à expiration dans trois jours. Une nouvelle version introduit un bug qui fait planter une requête sur vingt — mais seulement pour les utilisateurs connectés. Rien de tout ça ne se voit tant que tu ne regardes pas.

Le vrai risque en prod n’est pas la panne : c’est la panne que tu découvres trop tard, par le mauvais canal (un tweet, un mail furieux, un client au téléphone). Observer, c’est retourner la situation : c’est toi qui découvres le problème, calmement, souvent avant qu’il ne devienne visible. Cette partie transforme ta prod d’une boîte noire muette en un système qui te parle — par ses logs, ses métriques, ses alertes.

Ce que tu sauras faire à la fin de cette partie

• Lire les logs de ta machine et de ton app : journalctl, /var/log, filtrer, suivre en direct, et empêcher les logs de remplir le disque (rotation).
• Mesurer l’état de la machine avec les bons outils (htop, free -h, df -h, ss…) et identifier le goulot : CPU, RAM, I/O ou réseau.
• Passer du ponctuel au continu : mettre en place un monitoring (uptime + ressources) et des alertes sur les bons seuils, vers le bon canal.
• Surveiller l’application au-delà de la machine : erreurs applicatives, taux de 5xx, temps de réponse, healthcheck qui vérifie les dépendances.
• Construire le tableau de bord minimal d’un dev qui opère sa prod — et dormir tranquille.

Les chapitres

Cette partie te donne les yeux sur ta prod. La Partie 15 — Sauvegardes, résilience & scaling te donnera ensuite les réflexes quand, malgré tout, quelque chose casse : sauvegarder pour pouvoir restaurer, résister aux pannes, et grandir quand le trafic monte.

On commence : Les logs — apprendre à lire la boîte noire de ta machine.