feat(monitoring) : les métriques des conteneurs remontent par un relais #30
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/container-metrics-relay"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Jumeau du relais de journaux (PR #26), pour les métriques. Déployé et mesuré le 10/08/2026 sur les quatre nœuds et leurs huit conteneurs — voir en bas. Il précède le démontage des coffres des nœuds : dans l'autre sens il existerait une fenêtre pendant laquelle un magasin de certificats tourne sans témoin.
Le problème, et l'option écartée
Le coffre est descendu en conteneur. Or
openbao-metricstourne sur le nœud et lit des fichiers locaux : certificat de listener, âge du token de stockage, instantanés du raft.L'option bon marché — sonder les quatre coffres depuis le nœud, en DN42 — récupérait cinq métriques sur huit. Elle perdait l'âge des instantanés et l'âge du token, c'est-à-dire exactement les deux pannes muettes pour lesquelles ce collecteur avait été écrit :
Écartée pour cette raison.
Ce que le relais achète
Les mêmes deux choses que celui des journaux : le mot de passe de l'ingest ne descend pas dans les conteneurs, et aucune destination du plan privé n'est ouverte — le pont étant NATé, une telle règle aurait valu pour tous les conteneurs du nœud, vers un service qui accepte des écritures.
Le découpage suit ce que chaque machine peut VOIR
openbaoingress, où Caddy le litPas un découpage administratif : c'est le propriétaire du fichier qui décide. Les chemins étant identiques à l'intérieur d'un conteneur, les scripts n'ont pas eu à apprendre où ils tournent — ils ont cessé de chercher ce qui n'est plus chez eux. Les métriques gardent leurs noms ; seule
instancechange.⚠ Un conteneur ne pousse QUE ses collecteurs textfile
set_collectorset nonenable_collectors: le second ajoute aux défauts de node_exporter — cpu, mémoire, disque. Les prendre aurait fait remonter par conteneur une mesure que le nœud fait déjà, et à moitié fausse : un conteneur voit le CPU de son hôte.Quatre défauts trouvés en déroulant, dont trois muets
Aucun ne se voyait au lint. Ils sont dans le second commit.
1. Le chemin du récepteur —
/api/v1/metrics/write, celui d'Alloy, et non/api/v1/write, celui de Prometheus. Le mauvais rend 404 etremote_writeréessaie sans fin sans rien journaliser en niveau info : le conteneur avait l'air de pousser, le relais d'écouter, et aucune série n'arrivait. Trouvé en interrogeant l'endpoint, pas en lisant les journaux — qui ne disaient rien.2.
instancene se pose pas dansexternal_labels. Unremote_writene les applique qu'aux étiquettes absentes, etprometheus.scrapea déjà poséinstance: le nom d'hôte. Sur un nœud ça ne se voyait pas — son nom d'hôte est son nom de nœud. Dans un conteneur c'est le nom du service, identique sur les quatre machines : les quatre coffres se seraient écrasés sous une seule série. Corrigé par undiscovery.relabel, seul endroit où l'étiquette peut l'être.3. Deux écouteurs gRPC sur le wildcard, que personne n'avait demandés :
Les composants d'écoute d'Alloy reposent sur un serveur interne qui ouvre toujours un gRPC à côté de l'HTTP, sur
*et un port éphémère si on ne dit rien. C'est ce que ce dépôt refuse partout ailleurs :tcp_l3mdev_acceptvaut 1 pour Bird, donc toute socket wildcard est joignable depuis tout l'overlay. La politiquedroples couvrait — mais compter sur le pare-feu pour rattraper une écoute qu'on ne voulait pas est l'inverse de l'invariant quelooking_glassetopenbaodéfendent chacun de leur côté. Épinglés sur la boucle locale, à ports fixes.4. Le handler des minuteries bouclait sur la liste des nœuds : dans un conteneur il tentait de redémarrer des minuteries jamais installées. Celui-là échouait franchement.
Un contrôle trouvé en chemin
alloy validateaccepte un répertoire et vérifie les références croisées entre fichiers —30-container-relaynomme des récepteurs définis dans00-base, ce qu'aucune validation fichier par fichier ne verrait.Vérifié qu'il vérifie plutôt que supposé : un composant inventé le fait échouer. C'est la leçon de
bao operator diagnose, qui rend 4 sur une configuration valide comme sur du HCL cassé. Sans lui, une erreur ne se manifestait qu'au redémarrage d'Alloy — par une télémétrie qui s'arrête en silence, c'est-à-dire la panne que la supervision devait dire.Déploiement et vérification (10/08/2026)
Les quatre nœuds puis leurs huit conteneurs, nœud par nœud.
10.42.0.1:3500et:3501, jamais le wildcard127.0.0.1:3502et:3503— plus aucun wildcard dansss -ltnptcp dport { 3500, 3501 }surincusbr0instance=<service>-<nœud>Exemple mesuré :
dn42_openbao_sealed{instance="openbao-fr-bod1"} 0,dn42_openbao_storage_token_age_seconds{instance="ingress-fr-rbx2"} 208.⚠ Les règles Mimir devront suivre (dépôt
ATNET/k8s-flux) : le groupedn42-openbaomatche desinstancequi étaient des noms de nœuds. Rien ne casse pendant l'intervalle — le collecteur des nœuds tourne encore, les coffres y sont toujours — mais les deux jeux de séries coexistent jusqu'au démontage, qui est le bon moment pour les faire suivre.Aucun changement de
topology/: pas de synchronisation NetBox à faire.