[42] Cinq alertes d'exploitation, notifiées dans la forge #152
No reviewers
Labels
No labels
Compat/Breaking
EC01
EC02
EC03
EC04
EC05
EC06
Kind/BDD
Kind/Back
Kind/Bug
Kind/CICD
Kind/Cloud
Kind/Contenu
Kind/Data
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Front
Kind/IA
Kind/Infra
Kind/Monitoring
Kind/Security
Kind/Testing
Portée/Post-jury
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
ops/alerte
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
g2/enervision!152
Loading…
Reference in a new issue
No description provided.
Delete branch "gabriel/42-alertes"
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?
Ferme #42 — cinq alertes d'exploitation (ENF-08, EC03).
Moteur : alerting unifié de Grafana, règles provisionnées par fichier (
grafana/provisioning/alerting/). Pas d'Alertmanager. Canal unique : un webhook versrelais-forge(nouveau service, ~200 lignes de bibliothèque standard, imagepython:3.12-alpinemontée telle quelle) qui ouvre une issue Forgejo assignée au destinataire nommé par la règle, et la referme à la résolution. Réseau clos : la forge est la seule destination, pas de relais SMTP (décision d'équipe).Les cinq alertes
/currentréussie/< 15 %up == 0La dernière ferme l'écart n°4 de
docs/POSTGRESQL.md(« aucune alerte sur échec — attend Prometheus »).Plomberie
collecte-current.shetpg-backup.shdéposent des métriquesev_ops_*dans/var/lib/node_exporter/textfile, republiées par node-exporter (flag--collector.textfile.directoryajouté)blackbox-exporterajouté à la pile (127.0.0.1:9115) ; jobblackboxdansprometheus.ymlsonde l'API source, la forge et Grafanaapp: création du répertoire textfile, garde devault_forge_alerte_tokendans l'asserttest-supervision.shétendu : cinq règles, destinataire nommé, point de contact webhook, aucun jeton en clair, YAML du provisioning valideAvant de fusionner
Créer le compte de service forge
ci-alertes+ jeton portéeissue→vault_forge_alerte_token. Le déploiement échoue tant que le secret est absent (garde dans l'assertdu rôleapp). Voirdocs/runbooks/supervision.md§ 7.Après déploiement
Déclencher une alerte en conditions réelles (renommer
/var/backups/postgresql, lancerpg-backup.sh) et joindre l'URL de l'issue horodatée au ticket #42 (preuve ENF-08). Ouvrir un ticket de suivi « régler les seuils après 24 h d'observation ».Validé localement
Provisioning chargé sans erreur par Grafana 11.6.3 (5 règles + point de contact + politique vus via l'API),
promtool check configOK, config blackbox OK (digest confirmé au pull), relais testé (chemins firing et resolved),test-supervision.sh/test-liens-markdown.sh/verifier-images.shverts.Relu sur
gabriel/42-alertes. Le fond est bon et le travail est propre : unseul point m'empêche d'approuver, plus deux remarques.
Ce qui est bien fait
L'écriture des métriques est atomique, avec le temporaire en
.prom.$$quenode-exporter ignore puisqu'il ne finit pas en
.prom. Et la garde[ -d ] && [ -w ] || return 0suivie du|| truemet la priorité au bonendroit : une métrique non publiée ne fait jamais échouer une relève. La
supervision n'est pas devenue une dépendance de la collecte.
La distinction entre
derniere_tentativeetderniere_reussiteest juste, etc'est bien la seconde qui porte l'alerte. Les deux nouvelles images sont
épinglées par empreinte. Et le relais répond toujours 200, avec la bonne raison
écrite dans le code : un 5xx ferait réémettre Grafana en boucle et rouvrirait des
issues en double.
Bloquant : l'assertion casse le déploiement entier, pas seulement l'alerting
Cette ligne est dans l'assertion d'entrée du rôle
app. Sans le jeton, ce n'estpas le relais qui échoue, c'est le rôle entier : collecteur, crontab,
migrations, piles. Or
deploy.ymljoue--tags app,proxy, donc une fusion versmainavant la création du compte casse tout le déploiement.Tu le signales dans la demande, donc ce n'est pas un oubli. Ce que je conteste,
c'est le choix : le rôle sait déjà faire mieux, depuis la #114.
Une pile dont le secret manque est sautée bruyamment, et le reste du socle part.
Le commentaire au-dessus le dit : « le déploiement suivant la ramassera ». Cette
assertion contredit ce motif.
Et il y a une seconde incohérence, interne à ta demande :
relais.pytolèrel'absence du jeton, il démarre et journalise un avertissement. Ansible refuse
donc de déployer pour un secret que le service accepte de ne pas avoir.
Concrètement : sortir le jeton de l'assertion d'entrée et traiter le relais comme
les autres piles, sauté si son secret manque. Le déploiement passe, l'alerting
attend le compte de service, et personne n'est bloqué entre-temps.
Remarque 1 : le relais n'authentifie rien
Tout ce qui atteint
127.0.0.1:9095peut ouvrir et fermer des issues dans ledépôt, sans secret partagé. C'est acceptable sur la boucle locale et je ne
demande pas de le changer maintenant. Mais ça mérite deux lignes dans
relais-forge/README.mdcomme risque assumé, d'autant que l'exécuteur partage lamachine et a la socket Docker, ce qui est le #103.
Remarque 2 : des temporaires orphelins
Si un script est tué entre l'écriture et le renommage, le
.prom.$$reste pourtoujours. Sur des mois, dans un répertoire lu à chaque scrape, ça s'accumule. Un
trapde nettoyage ou unfind -mmin +60 -deletesuffirait.Et un fait, pas une remarque
Conflit sur
vault.yml.example: ta clé et la mienne se croisent. Trentesecondes.
Le reste, provisioning Grafana, blackbox, extension de
test-supervision.sh, nem'inspire rien à redire.
Merci pour la relecture. Les quatre points sont traités dans
0a59d46:vault_forge_alerte_tokensorti de l'assertion d'entrée du rôleapp. Sans jeton, les quatre piles partent quand même ; seul l'alerting attend le compte de service, cohérent avec la tolérance derelais.pylui-même.relais-forge/README.mdsur l'absence d'authentification du webhook, avec le lien vers le #103..prom.$$de plus d'une heure ajoutée danscollecte-current.shetpg-backup.sh, avant toute écriture.vault.yml.example: les deux clés (#42 et #141) coexistent maintenant.Ça te va pour lever le REQUEST_CHANGES ?
Sortir vault_forge_alerte_token de l'assertion d'entrée était le bon geste, mais supervision.env.j2 l'interpole toujours sans garde et la clé n'est dans aucun coffre : vault.yml est identique à celui de develop, develop ne référence la variable nulle part, et le compte de service ci-alertes n'existe pas encore. Rejoué en local sur le gabarit réel, sans la clé : fatal: [localhost]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result"} 'vault_forge_alerte_token' is undefined La tâche « Rendre les secrets de supervision » est la dixième sur trente du rôle app. Tout ce qui suit ne tourne pas : MinIO, le certificat TLS, les quatre piles, l'environnement Python, la crontab, les migrations. Et comme deploy.yml joue --tags app,proxy, c'est le déploiement continu entier. La garde est dans le gabarit et pas dans defaults/main.yml : ansible-lint exige le préfixe app_ pour toute variable posée dans les défauts d'un rôle (var-naming[no-role-prefix], profil moderate), ce qui aurait fait rougir la chaîne. Le gabarit est de toute façon l'endroit où le caractère facultatif du jeton se lit. Éprouvé dans les deux sens : sans la clé le rendu donne FORGE_ALERTE_TOKEN=, avec une clé au coffre il donne sa valeur. ansible-lint passe au profil production, tests/ci/test-supervision.sh reste vert.Tes quatre corrections tiennent, je les ai vérifiées une par une dans
0a59d46.La purge des temporaires est bien placée, avant toute écriture, et son motif
*.prom.[0-9]*ne peut pas attraper un.promlégitime. Le commentaire quiremplace la ligne d'assertion explique le choix mieux que ma remarque ne le
demandait.
J'ai poussé deux commits sur ta branche plutôt que de te renvoyer un aller
retour. Voilà ce que j'ai changé et pourquoi.
Le correctif a déplacé la panne d'une dizaine de tâches
Sortir
vault_forge_alerte_tokende l'assertion d'entrée était le bon geste.Mais
supervision.env.j2l'interpole toujours sans garde, et la clé n'est dansaucun coffre :
Rejoué en local sur ton gabarit réel, sans la clé :
« Rendre les secrets de supervision » est la dixième tâche sur trente du
rôle
app. Tout ce qui suit ne tourne pas : MinIO, le certificat TLS, lesquatre piles, l'environnement Python, la crontab, les migrations. Et comme
deploy.ymljoue--tags app,proxy, c'est le déploiement continu entier.C'est le même effet que ce que je t'avais signalé, un cran plus loin dans le
fichier. Ansible nomme quand même la variable en défaut, donc ce n'est pas
muet, mais le
fail_msgqui disait quoi faire a disparu au passage.Ce que j'ai posé
La garde est dans le gabarit et pas dans
defaults/main.yml, où je l'avaismise d'abord.
ansible-lintrefuse toute variable sans le préfixeapp_dansles défauts d'un rôle (
var-naming[no-role-prefix], profilmoderate), donccette version aurait fait rougir la chaîne. Le gabarit est de toute façon
l'endroit où le caractère facultatif du jeton se lit, à côté des trois secrets
qui, eux, restent exigés.
Éprouvé dans les deux sens : sans clé le rendu donne
FORGE_ALERTE_TOKEN=,avec une clé au coffre il donne sa valeur. Le comportement est celui que ton
commentaire promet déjà, et
relais.pyfait le reste.Et j'ai fusionné develop
La demande était repassée en conflit sur
vault.yml.example, le fichier que tuvenais justement de démêler, plus
docs/PRD.mddepuis la fusion de la #157.vault.yml.example: les deux clés coexistent, comme dans ton commit. J'airetiré la note qui expliquait la reprise manuelle depuis develop, elle n'a
plus d'objet maintenant que develop la fournit.
PRD.md, ENF-08 : j'ai gardé la ligne de develop. La tienne annonçait lescinq alertes comme livrées alors que la demande est encore ouverte. À toi de
la remettre à jour une fois fusionnée, c'est ton document.
Vérifications
La demande est repassée fusionnable.
Ce qui reste, et ce n'est pas du code
Le compte de service
ci-alerteset son jeton, portéeissuesurg2/enervisionseulement, puis la clé dansgroup_vars/all/vault.yml. Tantque ce n'est pas fait, la pile part et l'alerting se tait en le journalisant.
Rien n'est bloqué entre temps, c'est le but.
Ça te va comme ça ? Si oui je lève ma demande de modification. Si tu préfères
une autre forme pour la garde, ou que je défasse la fusion pour la refaire
toi même, dis le et je m'aligne.
C'est en place, tout est sur ta branche.
Le compte de service
La restriction au dépôt vient bien du compte, pas du jeton : le schéma de l'API
ne connaît que des portées par catégorie,
write:issueet compagnie, sans champdépôt. Écrire « jeton scopé à g2/enervision » quelque part décrirait une
garantie qui n'existe pas.
Le coffre
vault_forge_alerte_tokenest dansgroup_vars/all/vault.yml, commit874fbff.Le fichier reste chiffré en AES256, seule sa taille change.
Ma garde
default('')danssupervision.env.j2ne se déclenchera donc plus.Je la laisse : elle documente pourquoi ce secret est le seul du fichier à en
avoir une, et elle protège la cible neuve qui n'aurait pas encore son compte de
service.
Ce qui reste à ta main
La ligne ENF-08 du PRD, comme tu l'as dit, une fois la demande fusionnée. Et le
runbook
docs/runbooks/supervision.md§7 si tu veux y noter que le compteexiste maintenant.
Je lève ma demande de modification dès que la chaîne est verte. Bon travail sur
les quatre corrections, la purge des temporaires et le commentaire de
l'assertion étaient meilleurs que ce que ma relecture demandait.
Cinq contrôles verts, y compris « Aucun secret commité » sur le coffre modifié.
Je lève ma demande de modification. Les quatre points de ma relecture sont
traités, le cinquième que j'avais manqué est corrigé sur ta branche, le compte
de service existe et le jeton est au coffre.
La demande est fusionnable.
New commits pushed, approval review dismissed automatically according to repository settings