Chapitre 14.3 — Monitoring & alerting

⏱️ TL;DR — Les logs et htop sont formidables… quand tu es devant l’écran. Mais la prod tombe la nuit, le week-end, pendant tes vacances. Le monitoring enregistre l’état en continu et — surtout — l’alerting te prévient quand quelque chose déraille. Deux briques : le monitoring d’uptime (« est-ce que le site répond, vu de l’extérieur ? ») avec Uptime Kuma (auto-hébergé) ou des services comme UptimeRobot et healthchecks.io ; et le monitoring de ressources (CPU, RAM, disque dans le temps) avec Netdata (léger, temps réel) ou la stack de référence Prometheus + Grafana. Le tout piloté par des seuils (disque >85%, cert qui expire, service down) qui déclenchent une alerte vers un canal (email, Slack, Telegram). Le principe absolu : être prévenu AVANT l’utilisateur. Et sur un petit VPS, on commence simple — on ne se noie pas dans l’outillage.

🎯 Objectifs

Distinguer le monitoring d’uptime (le site répond-il ?) du monitoring de ressources (comment se porte la machine ?).
Mettre en place un healthcheck HTTP et surveiller la disponibilité avec Uptime Kuma.
Situer Netdata et la stack Prometheus + Grafana pour les métriques dans le temps.
Définir de bons seuils d’alerte et choisir un canal de notification.
Ne pas sur-outiller un petit VPS : commencer par le minimum qui protège vraiment.

Du ponctuel au continu : pourquoi

Le chapitre précédent t’a donné les outils du diagnostic à chaud. Mais ils partagent tous une faiblesse : ils exigent que tu sois là, à taper la commande. Or les pannes n’attendent pas que tu regardes.

Le monitoring continu renverse le rapport de force : au lieu d’aller chercher l’information, c’est elle qui vient à toi, au moment où ça compte. Sa règle d’or tient en une phrase : tu dois apprendre la panne par ton alerte, jamais par un utilisateur mécontent.

⚠️ Piège — Découvrir sa propre panne par un client furieux (ou pire, un tweet public). C’est le pire scénario : non seulement le service était down, mais tu l’as appris en dernier, tu as perdu du temps et de la crédibilité. Un monitoring d’uptime, même gratuit et posé en dix minutes, t’aurait prévenu avant. L’absence d’alerting n’est pas une économie, c’est une dette qui se paie au plus mauvais moment.

Brique 1 : le monitoring d’uptime

La question la plus simple et la plus importante : « mon site répond-il, vu de l’extérieur ? ». Un outil externe interroge ton URL à intervalle régulier (toutes les 30 s, chaque minute) et vérifie qu’il obtient une réponse correcte (un code 200, un contenu attendu). S’il n’obtient rien, un timeout, ou une erreur → alerte.

Le healthcheck HTTP

On ne se contente pas de la page d’accueil : on expose un endpoint dédié, par convention /health (ou /healthz), léger et rapide, qui répond 200 OK quand l’app va bien. Le moniteur tape /health ; s’il ne reçoit pas 200, il déclenche. On enrichira ce endpoint au chapitre 14.4 pour qu’il vérifie aussi la base et les dépendances.

Uptime Kuma (auto-hébergé)

Uptime Kuma est un moniteur d’uptime auto-hébergé, très populaire, à l’interface soignée. Tu le fais tourner sur ton VPS (typiquement dans un conteneur Docker, cf. Partie 12), tu lui déclares tes URL à surveiller, tes seuils, tes canaux d’alerte, et il veille.

💡 Réflexe — Si tu héberges Uptime Kuma sur le même VPS que ton app, et que le VPS entier tombe (panne matérielle, réseau coupé), Uptime Kuma tombe avec et ne t’alertera pas. La parade : doubler avec un moniteur externe gratuit (UptimeRobot, healthchecks.io) qui, lui, surveille depuis l’extérieur. Ceinture (Kuma, riche et interne) et bretelles (un ping externe, pour le cas où tout le VPS meurt).

Les services externes

UptimeRobot : service hébergé (offre gratuite) qui ping ton URL depuis l’extérieur et t’alerte. Zéro maintenance, complémentaire de Kuma.
healthchecks.io : spécialisé dans la surveillance des crons et tâches planifiées, par « dead man’s switch » — ta tâche doit pinguer un URL à chaque exécution ; si le ping manque (le cron n’a pas tourné), healthchecks t’alerte. C’est LA façon de savoir qu’une sauvegarde nocturne a échoué (on y reviendra en Partie 15).

🔒 Sécurité — Un moniteur d’uptime surveille aussi, indirectement, ta sécurité. La disponibilité qui s’effondre peut trahir une attaque (DDoS). Et beaucoup d’outils, dont Uptime Kuma, savent surveiller l’expiration du certificat TLS : une alerte « le cert expire dans 14 jours » évite le classique site en erreur de sécurité un dimanche parce que le renouvellement Let’s Encrypt a silencieusement échoué (cf. Partie 8).

Brique 2 : le monitoring de ressources

L’uptime dit si le site répond, pas comment se porte la machine. Pour voir le CPU, la RAM, le disque évoluer dans le temps (et anticiper la saturation avant qu’elle ne cause une panne), il faut enregistrer les métriques en continu.

Netdata (léger, temps réel)

Netdata s’installe en une commande et offre immédiatement un dashboard temps réel très riche (CPU, RAM, disque, I/O, réseau, par service), avec une résolution à la seconde. C’est le choix pour un VPS unique : léger, zéro configuration pour démarrer, et il détecte tout seul ce qu’il y a à surveiller. Il sait aussi alerter sur des seuils.

Prometheus + Grafana (survol, la référence)

Pour des besoins plus ambitieux (plusieurs serveurs, historique long, dashboards sur mesure, requêtes complexes), la stack de référence est Prometheus + Grafana :

Prometheus collecte et stocke les métriques dans le temps (il « scrape » des exporters qui exposent les chiffres), et gère les règles d’alerte.
Grafana est la couche de visualisation : des tableaux de bord riches et configurables au-dessus des données de Prometheus.

C’est puissant, standard dans l’industrie… et lourd à opérer. On la cite comme horizon, on ne l’impose pas à un premier VPS.

⚠️ Piège — Sur-outiller un petit projet. Déployer Prometheus + Grafana + alertmanager pour surveiller un VPS qui héberge un site, c’est se donner une seconde infrastructure à maintenir (qui peut elle-même tomber) pour un bénéfice marginal. La complexité du monitoring doit suivre celle de ce qu’il surveille — pas la précéder. Commence simple.

Définir de bons seuils et un canal

Un monitoring sans alerte ne sert qu’après coup. L’alerting, c’est seuil + canal.

Les seuils doivent viser le point où il faut agir, pas là où c’est déjà cassé. Quelques valeurs de départ raisonnables :

Signal	Seuil d’alerte typique	Pourquoi
Disque `/`	`>85%`	Laisse le temps d’agir avant le disque plein (la panne en cascade).
Site / healthcheck	pas de `200` sur 2 checks	Confirme un vrai down (évite les fausses alertes sur un hoquet).
Certificat TLS	expire dans `<14 jours`	Marge pour réparer un renouvellement échoué.
Service down	unit systemd inactive	L’app ne tourne plus.
RAM / swap	swap qui se remplit durablement	La RAM sature, l’OOM menace.

Le canal doit t’atteindre là où tu es : email (simple, universel), Slack/Discord (pour une équipe), Telegram (notification push fiable sur mobile). La plupart des outils (Uptime Kuma, Netdata) gèrent plusieurs canaux nativement.

💡 Réflexe — Attention à la fatigue d’alerte. Une alerte qui se déclenche pour un rien (seuil trop bas, hoquet réseau d’une seconde) finit ignorée — et le jour où elle est vraie, tu ne la lis plus. Règle : peu d’alertes, mais fiables et actionnables. Chaque alerte doit répondre à « que dois-je faire, là, maintenant ? ». Si la réponse est « rien », le seuil est mauvais.

📚 La doc — Chaque outil a sa doc d’alerting (Uptime Kuma : « Notifications » ; Netdata : « health alarms »). Consulte-la pour brancher ton canal (webhook Slack, bot Telegram, SMTP email) plutôt que de recopier une config trouvée au hasard : les formats de webhook changent.

Par où commencer (le minimum utile)

Pour un premier VPS, la pile minimale qui protège vraiment, dans l’ordre de priorité :

Un moniteur d’uptime sur ton URL principale + un endpoint /health, avec alerte email. (Uptime Kuma, ou même juste UptimeRobot pour démarrer.)
Une alerte disque >85% et une alerte cert qui expire. Les deux pannes les plus fréquentes et les plus évitables.
Netdata pour avoir un dashboard de ressources sous la main quand tu diagnostiques.

C’est tout ce qu’il faut pour ne plus jamais découvrir une panne par un client. Le reste (Prometheus/Grafana, dashboards sur mesure) viendra si et quand l’échelle le justifie.

🧭 Sur FormaCampus — L’équipe a posé Uptime Kuma sur le VPS. Il surveille formacampus.fr (le front) et api.formacampus.fr (l’API Symfony) via leurs endpoints /health, toutes les minutes, avec alerte Telegram (notification immédiate sur le mobile de l’astreinte) et email. Deux alertes clés sont branchées : disque >85% (l’incident du log qui remplit le disque ne se reproduira pas sans prévenir) et certificat TLS <14 jours. Pour parer au cas où le VPS entier tombe, un ping UptimeRobot externe double la surveillance. Netdata tourne pour le diagnostic à chaud. Résultat : la dernière micro-coupure, ils l’ont apprise par une notif Telegram à 3 h 12, corrigée avant l’arrivée des premiers apprenants le matin.

✏️ Exercices

Exercice 1 — Kuma suffit-il ? Tu héberges Uptime Kuma sur le même VPS que ton app pour surveiller mon-site.fr. Un ami dit : « c’est bon, tu es couvert ». Quel angle mort reste-t-il, et comment le combler ?

✅ Solution

L’angle mort : si le VPS entier tombe (panne matérielle, réseau, kernel panic), Uptime Kuma tombe avec lui et ne peut pas t’alerter — tu ne sauras rien de la panne la plus grave. La parade : doubler avec un moniteur externe (UptimeRobot, healthchecks.io) qui surveille mon-site.fr depuis l’extérieur du VPS. Kuma en interne (riche, complet) + un ping externe (pour le cas où tout le VPS meurt) = ceinture et bretelles.

Exercice 2 — Choisis les seuils. Ton VPS héberge un site vitrine à trafic modéré. Propose trois alertes prioritaires avec leur seuil, et justifie pourquoi ces trois-là d’abord.

✅ Solution

(1) Uptime du site (pas de 200 sur /health, confirmé sur 2 checks) : c’est la question qui compte, « le site répond-il ? ». (2) Disque >85% : la panne « disque plein » est fréquente, sournoise (logs qui s’accumulent) et catastrophique, mais elle prévient si on surveille — 85% laisse le temps d’agir. (3) Certificat TLS <14 jours : un renouvellement Let’s Encrypt qui échoue en silence casse le site en erreur de sécurité ; 14 jours donnent une marge de réparation. Ces trois-là couvrent les pannes les plus probables et les plus évitables, avec très peu de fausses alertes. Le canal : email (voire Telegram pour du push).

🧠 Quiz de révision

1. Quelle différence entre monitoring d’uptime et monitoring de ressources ?

Le monitoring d’uptime vérifie, depuis l’extérieur, que le site répond (healthcheck HTTP, code 200) — il dit si ça marche. Le monitoring de ressources enregistre dans le temps l’état de la machine (CPU, RAM, disque) — il dit comment elle se porte et laisse anticiper une saturation. Les deux sont complémentaires.

2. Pourquoi doubler Uptime Kuma (auto-hébergé) avec un moniteur externe ?

Parce que si le VPS entier tombe, Uptime Kuma — hébergé dessus — tombe aussi et ne peut plus alerter. Un moniteur externe (UptimeRobot, healthchecks.io) surveille depuis l’extérieur et détecte cette panne-là. Ceinture (interne) et bretelles (externe).

3. Qu’est-ce qu’un endpoint /health et à quoi sert-il ?

Un endpoint HTTP dédié (par convention /health ou /healthz), léger, qui répond 200 OK quand l’app va bien. Les moniteurs le pingent au lieu de la page d’accueil ; l’absence de 200 déclenche l’alerte. On peut l’enrichir pour qu’il vérifie aussi la base et les dépendances.

4. Netdata ou Prometheus + Grafana pour un premier VPS ?

Netdata : il s’installe en une commande, donne un dashboard temps réel riche sans configuration, et sait alerter — idéal pour un VPS. Prometheus + Grafana est la référence de l’industrie mais lourd à opérer ; on le réserve aux besoins ambitieux (plusieurs serveurs, historique long, dashboards sur mesure). Ne pas sur-outiller un petit projet.

5. Qu’est-ce que la “fatigue d’alerte” et comment l’éviter ?

C’est le fait qu’une alerte qui se déclenche trop souvent (seuils trop bas, hoquets) finit par être ignorée — et l’on rate la vraie. On l’évite avec peu d’alertes, fiables et actionnables : chaque alerte doit répondre à « que dois-je faire maintenant ? ». Si la réponse est « rien », le seuil est mauvais.

Chapitre suivant : Supervision applicative — surveiller non plus la machine, mais l’application elle-même.