Set-OPS-Public/roles/serveur_web_frontal/meta/supervision.yml

---
# 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.'
supervision : les huit derniers roles, et deux defauts que l epreuve a trouves Les 33 roles serveur_* declarent maintenant une sonde. Les huit qui manquaient sont ceux dont la verite ne ressemble pas a « ce service repond-il ». Quatre marqueurs du site : ce que tasks/main.yml verifie UNE FOIS au deploiement cesse d etre vrai sans que rien ne tombe. La racine du cache se retrouve chainee, la forge du genome repond en n ayant plus rien dedans, un locataire n est plus admis a resoudre, l isolation d un depot glisse. serveur_ops_site ne sert rien : il detient un pouvoir. La sonde verifie que la carte est la, que la voute du site est chiffree et que sa cle est en 0600 — sans lire le contenu d aucun des trois. serveur_icingaweb2 surveille la vitrine de la supervision elle-meme : si la console meurt, tout reste vert et l exploitant est aveugle. DEFAUT 1 — quatre gabarits qu Ansible aurait refuse de rendre. Jinja lit le {# de ${#tableau[@]} comme un debut de commentaire. Le depot connaissait le remede et l appliquait la ou quelqu un s etait fait prendre, nulle part ailleurs. P76 rend desormais chaque gabarit de role, avec les delimiteurs qu Ansible en tirerait — pas une recherche de motif. DEFAUT 2 — la doctrine promettait 54 greffons et citait check_pgsql. La flotte a monitoring-plugins-basic : 53, sans check_pgsql ni check_dns ni check_ldap. Le paquet qui les porte traine samba et snmp sur chaque machine. Un greffon absent sort en 127, qui n est pas un code Nagios. 21 controles negatifs sur les machines reelles du site. ansible-lint production 0/91, harnais 75 OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q 2026-09-14 15:43:52 -04:00			`---`
			`# 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.'