Daniel Allaire
a5d9040a11
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
26 lines
1.5 KiB
Django/Jinja
26 lines
1.5 KiB
Django/Jinja
#!/bin/bash
|
|
# GENERE par Set-OPS (role serveur_artefacts). Ne pas editer a la main.
|
|
#
|
|
# SONDE « cache-apt » — le cache repond-il ?
|
|
#
|
|
# Contrat : docs/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
|
|
# Mise en defaut PAR PARAMETRE : `serveur_artefacts_sonde_port` (port ferme).
|
|
#
|
|
# ELLE NE MESURE PLUS LE VOLUME, ET C'EST LE POINT (2026-09-10). Les deux etaient fondus
|
|
# dans une seule sonde. Or « le cache ne repond pas » arrete TOUT `apt` de l'ecosysteme —
|
|
# on agit dans la minute — tandis que « le volume est a 90 % » est un billet pour demain.
|
|
# Meme personne, meme geste peut-etre, mais pas le meme DELAI : les fondre obligeait soit
|
|
# a reveiller quelqu'un pour un disque, soit a traiter une panne comme un billet.
|
|
#
|
|
# Le volume vit desormais dans `cache-apt-volume`, avec son propre etat, son propre
|
|
# historique et son propre acquittement.
|
|
set -uo pipefail
|
|
|
|
PORT={{ serveur_artefacts_sonde_port }}
|
|
|
|
# ON DEMANDE UNE PAGE, ON NE SE CONTENTE PAS D'UN connect(). Un `connect()` reussit contre
|
|
# un processus mort-vivant qui n'a plus rien a servir ; seule une reponse prouve le
|
|
# service. C'est la lecon du depot : « un connect() TCP ne prouve rien ».
|
|
code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 8 "http://127.0.0.1:${PORT}/acng-report.html" 2>/dev/null)
|
|
[[ "${code}" == "200" ]] || { echo "Le cache ne repond pas sur ${PORT} (HTTP ${code:-aucune reponse}) — tout apt de l'ecosysteme echoue."; exit 2; }
|
|
echo "Cache apt : repond sur ${PORT}."
|