Application de ce que l entree precedente avait prepare : 49 regles creees,
5 retirees. Cibles Prometheus 2/8 -> 8/8, hotes dans Loki 1/7 -> 7/7.
Puis correction de ce que l application a revele. Cinq defauts, tous de la
meme famille : un reglage qui ne suit pas l interrupteur dont il depend.
- la sonde de Loki interrogeait en HTTPS un Loki servant en clair ;
- la sonde de la forge visait http:// sur un port 443 chiffre, puis
validait un certificat emis pour le FQDN en interrogeant 127.0.0.1 ;
- la sonde du runner comparait six depots a UNE branche quand le plan en
declare une par depot. Elle contredisait la declaration qu elle etait
censee verifier : elle n accusait pas la machine, elle s accusait
elle-meme.
Le tenant restait juste dans les cinq cas. C est le site, qui deploie ces
roles autrement, qui les a tous reveles d un coup.
La sonde des journaux, elle, avait deux defauts a la naissance. Elle criait
une perte deja reparee, faute de dire sur QUELLE fenetre - un ecart sans sa
fenetre n est pas une mesure, c est un nombre. Et elle alertait sur la
cicatrice plutot que sur la plaie : le compteur d Alloy est cumulatif, donc
six machines restaient orange pour toujours. Ce qui alerte est desormais la
CROISSANCE. En echange, un cas muet leve maintenant : zero envoi et zero
rejet n est pas la sante, c est un agent qui ne fait rien.
Enfin, le runner ne pouvait plus cloner le genome. Defaut PREEXISTANT,
revele par le redeploiement et non cause par lui - le diff des regles
generees le montre. generer_nftables(site=True) lisait le plan du TENANT :
derive se resolvait donc a 3000, le port que Forgejo ecoute derriere un
edge, alors que le plan du site dit 443 et explique pourquoi. La forge
ouvrait un port que personne n ecoute et laissait 443 ferme a toute la
flotte.
Mesure finale : Icinga 51/51, Prometheus 8/8, Loki 7/7, prouver 64 OK,
lint 0 defaut sur 82 fichiers. Controles negatifs sur des COPIES des
sondes : les quatre rendent CRITICAL.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
|
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
client_journal
Intégration cliente journaux : expédie le journal système (journald) de la VM
vers serveur_loki, via Grafana Alloy.
Rôle
- Ajoute le dépôt apt Grafana et installe
alloy. - Ajoute l'utilisateur
alloyau groupesystemd-journal(lecture du journal). - Déploie
/etc/alloy/config.alloy:loki.source.journal→loki.writevers Loki.
Boucle
VM dans client_journal → Alloy lit journald → pousse vers Loki (obs-01) →
visible dans Grafana (datasource Loki).
Variables
| Variable | Défaut | Rôle |
|---|---|---|
client_journal_loki_url |
http://10.0.14.11:3100/loki/api/v1/push |
Endpoint Loki (obs-01) |
Notes / limites
- La syntaxe de configuration Alloy évolue entre versions ; la config fournie
cible un Alloy récent (
loki.source.journal,loki.write). Ajustement mineur possible selon la version installée. - Étiquettes par défaut :
job=systemd-journal,host=<inventory_hostname>.
Prérequis
- Dépendance
client_journal requiert serveur_loki actif(déjà dansdocs/dependances-groupes.yml).