Healthchecks et monitoring

Prérequis : cours 2.2 (healthcheck compose) et 5.3 (3 voyants) ; sauvegardes et monitoring.

Pourquoi

« Le process tourne » ≠ « le service rend le service ». Un monitoring qui ne teste que le ping découvre la panne par les utilisateurs — autant ne rien monitorer. On surveille ce qui fait mal quand ça casse.

Concepts

• Healthcheck honnête : /api/health teste l'app et ses dépendances (base…), et inclut la version déployée. En incident, savoir quelle version répond fait gagner 10 minutes.
• Les 4 signaux : ressources hôte (disque > 80 %, mémoire/swap, load vs CPU), TLS (< 21 jours), backups (dump du jour + taille cohérente — un backup non vérifié n'existe pas), erreurs app (taux de 5xx — erreurs serveur HTTP —, logins en rafale, latence p95 — le temps sous lequel restent 95 % des requêtes — qui dérive).
• Alerte vs graphique : une alerte exige une action (« disque > 80 % → purger »). Sinon c'est un graphique : on le consulte le matin, on ne s'en fait pas réveiller. Dix alertes par jour = zéro lue.

Exemple

// /api/health : dépendances incluses
const dbOk = await pool.query("SELECT 1").then(() => true).catch(() => false);
return { ok: dbOk, version: "1.4.2" };

Note : ce sont ton reverse proxy et tes healthchecks Docker qui décident où va le trafic — ils ne doivent router que vers du healthy. (Les gros systèmes confient ça à un orchestrateur comme Kubernetes ; à ton échelle, proxy + healthchecks suffisent.)

Cas réel

Dashboard « tout vert » qui ne testait que le ping : la base était down depuis 2 h, le ping répondait. Depuis : health qui teste la base + alerte sur le health, pas sur le ping.

Pièges

• Monitorer le ping au lieu du métier : vert qui ment.
• Seuils sans action (« info : disque à 62 % » toutes les heures) : bruit qui tue l'attention.
• Dashboard à 5 outils : si répondre exige un tour du monde, on ne regarde jamais.

À retenir

Santé = dépendances + version, 4 signaux avec seuils, dashboard d'un coup d'œil, alertes actionnables.