Daniel Allaire
1832530f29
Ajout de meta/supervision.yml a six roles, chacun deposant sa propre sonde selon le contrat des greffons Nagios. DEUX PRINCIPES POSES AU DOCUMENT DE CONCEPTION, parce que la premiere sonde les a imposes : 1. UNE SONDE DOIT POUVOIR ETRE MISE EN DEFAUT PAR PARAMETRE. Cible et seuils sont des variables du role : on la prouve rouge avec un port ferme ou un seuil impossible, sur une machine reelle, sans rien casser, et aussi souvent qu on veut. Une sonde qu on ne peut prouver qu en cassant un service ne sera prouvee qu une fois. 2. LA SONDE VIT LA OU VIT LA VERITE. « Ce noeud est-il collecte ? » est une sonde de serveur_prometheus, pas de client_metrique : une seule y voit les N noeuds, et surtout elle voit le cas SILENCIEUX — celui qui a cesse d etre collecte ne peut pas s en plaindre. LES SIX : cache-apt (artefacts, repond + place), resolution (resolveur, zone interne ET Internet — deux chemins distincts), forge (forgejo, son propre /api/healthz), collecte (prometheus, 15/15 cibles), tableaux (grafana, base ok), ingestion (loki, PRET a ingerer, pas seulement en ecoute). TROIS FOIS J AI ECRIT LA SONDE AVANT DE MESURER, ET TROIS FOIS ELLE A EU TORT. La forge : port 443 et chemin des depots INVENTES — elle ecoute en 3000 derriere l edge et n a legitimement aucun depot. Loki : j ai conclu « panne persistante » sur deux lectures prises a quelques secondes d intervalle, juste apres un redemarrage ; l anneau etait ACTIVE et la reponse est passee a ready moins d une minute plus tard. Le delai de stabilisation est desormais un AVERTISSEMENT nomme, pas une panne. On demande au service ce qu il pense de lui-meme quand il sait le dire (healthz, /ready, /api/health) plutot que d inventer un critere de l exterieur. make prouver : CONFORME. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
37 lines
1.7 KiB
Django/Jinja
37 lines
1.7 KiB
Django/Jinja
#!/bin/bash
|
|
# GENERE par Set-OPS (role serveur_loki). Ne pas editer a la main.
|
|
#
|
|
# SONDE « ingestion » — l'ingesteur est pret, pas seulement le port ouvert
|
|
#
|
|
# Contrat : docs/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
|
|
# Mise en defaut PAR PARAMETRE : `serveur_loki_sonde_url` (port ferme).
|
|
set -uo pipefail
|
|
|
|
URL={{ serveur_loki_sonde_url }}
|
|
|
|
# `/ready` ET PAS UN connect(). Loki ouvre son port bien avant que son ingesteur ne soit
|
|
# pret ; pendant cette fenetre il accepte et perd. C'est exactement « un connect() ne
|
|
# prouve rien », applique a un demon qui demarre.
|
|
s=$(curl -sk --max-time 10 "${URL}/ready" 2>/dev/null)
|
|
[[ -n "${s}" ]] || { echo "Loki ne repond pas sur ${URL}."; exit 2; }
|
|
if printf '%s' "${s}" | grep -qi '^ready'; then
|
|
echo "Loki pret a ingerer."
|
|
exit 0
|
|
fi
|
|
|
|
# LE DELAI DE STABILISATION N'EST PAS UNE PANNE, ET LE MESSAGE LE DIT LUI-MEME.
|
|
# Apres un redemarrage, Loki repond « Ingester not ready: waiting for Ns AFTER BEING
|
|
# READY » — l'ingesteur EST pret, il purge son delai. Mesure du 2026-09-10 : l'anneau
|
|
# etait `ACTIVE` et la reponse est passee a `ready` moins d'une minute plus tard.
|
|
#
|
|
# J'ai d'abord conclu « panne persistante » sur deux lectures prises a quelques secondes
|
|
# d'intervalle, juste apres un redemarrage. Deux mesures rapprochees ne distinguent pas un
|
|
# etat d'un instant. On nomme donc ce cas pour ce qu'il est : un AVERTISSEMENT transitoire,
|
|
# pas une panne — sans pour autant le taire, parce qu'un delai qui ne finirait jamais
|
|
# serait, lui, une vraie panne.
|
|
if printf '%s' "${s}" | grep -qi 'after being ready'; then
|
|
echo "Loki sort d'un redemarrage (delai de stabilisation) : ${s:0:80}"
|
|
exit 1
|
|
fi
|
|
echo "Loki n'est PAS pret a ingerer : ${s:0:90}"
|
|
exit 2
|