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
35 lines
1.8 KiB
YAML
35 lines
1.8 KiB
YAML
---
|
|
# Supervision derivee du role. Voir docs/supervision-conception.md.
|
|
#
|
|
# CE QUE `serveur_artefacts` SURVEILLE DEJA, ET QU'ON NE REFAIT PAS : `cache-apt` (le
|
|
# cache repond sur son port) et `cache-apt-volume` (il lui reste de la place). Ces deux
|
|
# verdicts valent pour N'IMPORTE QUEL cache de la fabric.
|
|
#
|
|
# CE ROLE PORTE UNE AUTRE VERITE, ET ELLE N'EST VRAIE QUE POUR LUI : ce cache est la
|
|
# RACINE de la chaine. Aucun autre n'a Debian comme amont direct.
|
|
#
|
|
# VM du tenant -> cache du tenant -> cache du SITE -> Debian
|
|
#
|
|
# Deux choses peuvent cesser d'etre vraies sans que rien ne tombe :
|
|
#
|
|
# 1. LA RACINE SE RETROUVE CHAINEE. Quelqu'un configure un mandataire amont sur ce
|
|
# cache — et la chaine se referme sur elle-meme ou sur un cache qui n'existe plus.
|
|
# `tasks/main.yml` l'exige au deploiement ; plus personne ne le verifie ensuite.
|
|
#
|
|
# 2. LA RACINE NE REMPLIT PLUS. Le cache repond parfaitement — il sert ce qu'il a — et
|
|
# ne peut plus rien chercher chez Debian. `cache-apt` reste VERT.
|
|
#
|
|
# CE QUE LE FLUX DE CE ROLE DIT DEJA, MOT POUR MOT : sans sortie, « la chaine entiere se
|
|
# termine sur un cache vide [...] et ca ne se serait vu qu'au premier `apt update` d'un
|
|
# ecosysteme neuf — c'est-a-dire au pire moment ». La sonde deplace ce constat AVANT
|
|
# l'installation d'un locataire, au lieu de le laisser arriver pendant.
|
|
#
|
|
# 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: cache-site-racine
|
|
ttl: 5400
|
|
raison: 'Ce cache est-il toujours la RACINE de la chaine, et peut-il encore remplir ?
|
|
Un cache chaine sur lui-meme ou coupe de Debian repond parfaitement — il sert ce
|
|
qu''il a deja. La panne n''apparait qu''au premier `apt update` d''un ecosysteme
|
|
neuf, c''est-a-dire au pire moment.'
|