---
# Supervision derivee du role. Voir docs/supervision-conception.md.
#
# CE QUE `serveur_nginx` NE PEUT PAS DIRE. L'edge a sa sonde, et elle repond « nginx sert
# encore ». Ici la question est autre : CHACUN des sites declares se sert-il vraiment ?
#
# LA PANNE PROPRE A CE ROLE EST SILENCIEUSE, et elle vient du fait que le contenu n'est
# pas dans le role : il arrive par `git clone`/`pull` depuis une forge. Trois facons de
# perdre un site sans que nginx bronche :
#
#   1. LE DEPOT A CHANGE DE BRANCHE OU DE NOM — le pull echoue, le contenu reste celui de
#      la derniere fois qui a marche. Le site est en ligne, et vieux.
#   2. LE SOUS-DOSSIER SERVI A BOUGE (`public/` renomme en amont) — nginx rend 404 ou 403
#      sur un repertoire qui existe mais ne contient plus d'index.
#   3. LE CLONE EST VIDE — un depot neuf, ou une reconstruction qui n'a rien ramene. Meme
#      lecture que la forge du site le 2026-09-14 : tout repond, il n'y a rien dedans.
#
# Dans les trois cas l'edge est vert, le vhost existe, le port ecoute. Seul un GET sur le
# `server_name` du site dit la verite.
#
# UNE SEULE SONDE POUR TOUS LES SITES, parce qu'il n'y a qu'une CAUSE D'ACTION : aller
# voir cet hebergeur. Elle nomme celui qui manque — c'est ce dont on a besoin pour agir,
# et une sonde par site ferait N services a definir pour un seul geste.
#
# TTL de 5400 s pour un porteur qui passe aux 15 min : trois passages manques avant la
# peremption. Le silence alerte autant que l'echec.
sondes:
  - nom: sites-servis
    ttl: 5400
    raison: 'Chacun des sites statiques declares se sert-il encore ? Le contenu vient
      d''un depot git : une branche renommee, un sous-dossier deplace ou un clone vide
      laissent nginx parfaitement vert avec un site perime, vide, ou en 404. Seul un GET
      sur le `server_name` de chaque site le dit.'