cache-apt scindee — et la scission a revele que moteur aurait alarme a tort
LA SCISSION. cache-apt fondait deux causes aux DELAIS differents : « ne
repond pas » arrete tout apt de l ecosysteme, on agit dans la minute ;
« volume a 90 % » est un billet pour demain. Les fondre obligeait soit a
reveiller quelqu un pour un disque, soit a traiter une panne comme un
billet. Deux sondes, chacune avec son etat, son historique, son
acquittement — et prouvees INDEPENDANTES :
port ferme -> cache-apt CRITIQUE, cache-apt-volume OK
seuil impossible -> cache-apt OK, cache-apt-volume AVERTISSEMENT
CE QUE LA VERIFICATION A REVELE. Un resultat pousse et accepte (code 200)
n apparaissait pas en base. Hypothese testee et confirmee : IcingaDB n
ECRIT service_state QUE SUR CHANGEMENT D ETAT. Un OK identique repete ne
produit aucune ecriture ; un AVERTISSEMENT pousse ensuite est ecrit en 13 s.
Or la sonde moteur, ecrite quelques heures plus tot, lisait exactement
max(last_update) de service_state pour juger de la fraicheur. Elle
mesurait le CHANGEMENT. Sur un ecosysteme parfaitement STABLE — celui
qu on veut — plus rien ne change, last_update vieillit, et elle serait
passee en avertissement a 15 min puis en critique a 90. Une alarme qui se
declenche PARCE QUE tout va bien, avec un delai qui l aurait rendue
difficile a rattacher a sa cause.
La bonne source existait : icingadb_instance porte le battement du
synchroniseur, ecrit en continu. Releve a 1 s sur un systeme sain. Seuils
ramenes de 15/90 min a 1/5 min. Controle negatif rejoue.
Dix-huit services, tous verts sauf sauvegarde 7/9 (deja connu).
make prouver : CONFORME, 64 OK, 0 echec, 0 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-10 03:27:52 -04:00
|
|
|
#!/bin/bash
|
|
|
|
|
# GENERE par Set-OPS (role serveur_artefacts). Ne pas editer a la main.
|
|
|
|
|
#
|
|
|
|
|
# SONDE « cache-apt-volume » — reste-t-il de la place au cache ?
|
|
|
|
|
#
|
doc : rangee par lecteur, trois portes d'entree (architecture, setup, usage) et un index
README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas
Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index).
Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis.
QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires.
Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous-
dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 01:01:34 -04:00
|
|
|
# Contrat : docs/conception/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
|
cache-apt scindee — et la scission a revele que moteur aurait alarme a tort
LA SCISSION. cache-apt fondait deux causes aux DELAIS differents : « ne
repond pas » arrete tout apt de l ecosysteme, on agit dans la minute ;
« volume a 90 % » est un billet pour demain. Les fondre obligeait soit a
reveiller quelqu un pour un disque, soit a traiter une panne comme un
billet. Deux sondes, chacune avec son etat, son historique, son
acquittement — et prouvees INDEPENDANTES :
port ferme -> cache-apt CRITIQUE, cache-apt-volume OK
seuil impossible -> cache-apt OK, cache-apt-volume AVERTISSEMENT
CE QUE LA VERIFICATION A REVELE. Un resultat pousse et accepte (code 200)
n apparaissait pas en base. Hypothese testee et confirmee : IcingaDB n
ECRIT service_state QUE SUR CHANGEMENT D ETAT. Un OK identique repete ne
produit aucune ecriture ; un AVERTISSEMENT pousse ensuite est ecrit en 13 s.
Or la sonde moteur, ecrite quelques heures plus tot, lisait exactement
max(last_update) de service_state pour juger de la fraicheur. Elle
mesurait le CHANGEMENT. Sur un ecosysteme parfaitement STABLE — celui
qu on veut — plus rien ne change, last_update vieillit, et elle serait
passee en avertissement a 15 min puis en critique a 90. Une alarme qui se
declenche PARCE QUE tout va bien, avec un delai qui l aurait rendue
difficile a rattacher a sa cause.
La bonne source existait : icingadb_instance porte le battement du
synchroniseur, ecrit en continu. Releve a 1 s sur un systeme sain. Seuils
ramenes de 15/90 min a 1/5 min. Controle negatif rejoue.
Dix-huit services, tous verts sauf sauvegarde 7/9 (deja connu).
make prouver : CONFORME, 64 OK, 0 echec, 0 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-10 03:27:52 -04:00
|
|
|
# Mise en defaut PAR PARAMETRE : `serveur_artefacts_sonde_pct_avert` / `_pct_crit`.
|
|
|
|
|
#
|
|
|
|
|
# SEPAREE DE LA DISPONIBILITE (2026-09-10) : ce verdict-ci appelle un billet, pas un
|
|
|
|
|
# reveil. Un cache plein ne se plaint pas — il cesse simplement de servir ce qu'il n'a pas
|
|
|
|
|
# pu ecrire, et l'echec apparait chez les CLIENTS, loin d'ici. D'ou des seuils qui
|
|
|
|
|
# previennent au lieu de constater.
|
|
|
|
|
set -uo pipefail
|
|
|
|
|
|
|
|
|
|
REP={{ serveur_artefacts_sonde_repertoire }}
|
|
|
|
|
AVERT={{ serveur_artefacts_sonde_pct_avert }}
|
|
|
|
|
CRIT={{ serveur_artefacts_sonde_pct_crit }}
|
|
|
|
|
|
|
|
|
|
pct=$(df --output=pcent "${REP}" 2>/dev/null | tail -1 | tr -dc '0-9')
|
|
|
|
|
[[ -n "${pct}" ]] || { echo "Volume du cache illisible (${REP})."; exit 2; }
|
|
|
|
|
taille=$(du -sh "${REP}" 2>/dev/null | cut -f1)
|
|
|
|
|
|
|
|
|
|
if (( pct >= CRIT )); then
|
|
|
|
|
echo "Volume du cache a ${pct}% (${taille}) — il va cesser d'ecrire, et l'echec se verra chez les clients.|pct=${pct}%;${AVERT};${CRIT};0;100"
|
|
|
|
|
exit 2
|
|
|
|
|
fi
|
|
|
|
|
if (( pct >= AVERT )); then
|
|
|
|
|
echo "Volume du cache a ${pct}% (${taille}), seuil ${AVERT}%.|pct=${pct}%;${AVERT};${CRIT};0;100"
|
|
|
|
|
exit 1
|
|
|
|
|
fi
|
|
|
|
|
echo "Volume du cache : ${taille} sur un volume a ${pct}%.|pct=${pct}%;${AVERT};${CRIT};0;100"
|