Ce que vous voyez
L’état opérationnel devient incomplet; cette fonction ne prévient encore aucun humain à elle seule.
État d’avancement:Essai localfiche de référencemise en service interdite pour l’instantÉtat réel:Alertmanager 0.33.1 A/B réelspasses=2totalRuntimePasses=3doublons physiques, état durable uniqueNO-GO
Choisissez votre lectureCommencez par la vue sans jargon si vous découvrez le sujet.
À qui s’adresse chaque lecture?
Je veux comprendre: direction, équipes métier, communication, achats et première visite. Exploitation: opérateur, support et astreinte. Vue architecte: architecte, ingénieur et sécurité. Tout afficher: revue complète de la fiche.
« Je veux comprendre » affiché. Ce choix sera repris sur les autres fiches. La décision de mise en service et les risques restent toujours visibles.
Comprendre cette fonction en 60 secondes
Le résumé donne le rôle, le trajet, le risque, le responsable et la limite de preuve en moins d’une minute. Les dépendances et exemples restent disponibles juste après, sans jargon imposé.
Résumé essentiel
Ce que c’est et à quoi cela sert
Conserver l’état des alertes.
Reconnaître les copies d’une même alerte et suivre si le problème est actif ou résolu.
Une comparaison utile
Comme un registre d’incidents: il reconnaît les copies et suit leur état.
Ce qui entre
Les deux chemins de supervision envoient parfois la même alerte plusieurs fois.
Qui en bénéficie et quel résultat attendre
Une seule situation cohérente est conservée pour l’exploitation.
L’équipe chargée de détecter et traiter les pannes.
État actuel
Essai local. Trois essais locaux couvrent deux arrêts puis un lien isolé. Le suivi converge sans doublon durable. Production et humain restent à prouver. Mise en service interdite pour l’instant.
Risque principal
L’état opérationnel devient incomplet; cette fonction ne prévient encore aucun humain à elle seule.
Responsable
Responsable de l’état local des alertes. Autorité de décision: Responsable des opérations.
Décision suivante
Autoriser le service lorsqu’il conserve un seul état cohérent pour chaque problème actif ou résolu.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Les deux chemins de supervision envoient parfois la même alerte plusieurs fois.
Ce dont il dépend
Des deux services qui regroupent les alertes, du stockage local et du service candidat qui doit transmettre les changements d’état au suivi des opérations.
Comment le service continue
L’équipe vérifie manuellement les étapes voisines. Les appels continuent seulement si leur chemin est indépendant; aucune notification humaine ne doit être supposée.
En cas de panne et pour vos données
Ce registre garde l’état de chaque problème, actif ou terminé. Si deux signalements identiques arrivent, un seul est conservé. Après un arrêt brutal, il reprend sans répéter un effet déjà enregistré. Tout reste sur la machine privée; si son stockage est perdu, l’historique ne peut pas encore être retrouvé.
Preuve attendue avant la prochaine étape
Essais de doublon, redémarrage, résolution tardive, stockage plein, reprise et mise à l’écart des éléments en échec.
Statut expliqué
Deux essais ont arrêté la première copie du programme qui regroupe les alertes, proprement puis brutalement, pendant que la seconde terminait le suivi. Un troisième a coupé seulement leur lien de coordination tout en gardant les deux copies actives. Le vrai service de réception a vu leurs envois en double, mais le stockage et les étapes suivantes n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. Il reste à relier le vrai détecteur de pannes en amont, à répéter les bascules et d’autres coupures réseau, à démarrer les services comme en production, à prouver reprise, restauration, charge et délais, puis à brancher et tester la prise en charge humaine.
Exemple concret
Les deux chemins de supervision envoient parfois la même alerte plusieurs fois. Une seule situation cohérente est conservée pour l’exploitation.
Voir l’exemple technique précis
Deux copies de la même génération ne créent qu’un état, même avec un EndsAt provisoire ou résolu différent.
Voir les questions et réponses selon votre rôle
Les six lectures ci-dessous reprennent les mêmes faits. Elles ne créent pas une seconde source de vérité.
- Direction
- Question: Peut-on compter sur cette fonction aujourd’hui?
Réponse: Deux essais ont arrêté la première copie du programme qui regroupe les alertes, proprement puis brutalement, pendant que la seconde terminait le suivi. Un troisième a coupé seulement leur lien de coordination tout en gardant les deux copies actives. Le vrai service de réception a vu leurs envois en double, mais le stockage et les étapes suivantes n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. Autoriser le service lorsqu’il conserve un seul état cohérent pour chaque problème actif ou résolu. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Reconnaître les copies d’une même alerte et suivre si le problème est actif ou résolu. Une seule situation cohérente est conservée pour l’exploitation. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: Des deux services qui regroupent les alertes, du stockage local et du service candidat qui doit transmettre les changements d’état au suivi des opérations. Il reste à relier le vrai détecteur de pannes en amont, à répéter les bascules et d’autres coupures réseau, à démarrer les services comme en production, à prouver reprise, restauration, charge et délais, puis à brancher et tester la prise en charge humaine. Preuve attendue: Essais de doublon, redémarrage, résolution tardive, stockage plein, reprise et mise à l’écart des éléments en échec. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Reconnaître les copies d’une même alerte et suivre si le problème est actif ou résolu. Ne présentez pas cette fonction comme disponible en production: Deux essais ont arrêté la première copie du programme qui regroupe les alertes, proprement puis brutalement, pendant que la seconde terminait le suivi. Un troisième a coupé seulement leur lien de coordination tout en gardant les deux copies actives. Le vrai service de réception a vu leurs envois en double, mais le stockage et les étapes suivantes n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. - Exploitation
- Question: Qui agit et quel est le premier geste sans risque?
Réponse: Responsable de l’état local des alertes. Autorité de décision: Responsable des opérations. Vérifier l’heure du dernier état et les étapes juste avant et après. Un silence de supervision ne signifie jamais que tout va bien. - Technique
- Question: Où sont les contrats exacts?
Réponse: Utilisez la « Vue architecte ». Elle montre les entrées, les sorties, les interfaces, les données, la sécurité et les preuves provenant de la fiche d’autorité.
Trajet simple, de la situation au résultat
Le trajet montre ce qui déclenche cette fonction, le service qu’elle rend et le résultat obtenu. Il reste lisible sans fonction interactive.
Suivre le flux
Partie documentée: Conserver l’état des alertes.
Les deux chemins de supervision envoient parfois la même alerte plusieurs fois.
Reconnaître les copies d’une même alerte et suivre si le problème est actif ou résolu.
Une seule situation cohérente est conservée pour l’exploitation.
Comment lire ce trajet: avancez avec les flèches du clavier ou parcourez les étapes dans l’ordre. Les contrats exacts restent dans la « Vue architecte ».
Étape 1 sur 3: Les deux chemins de supervision envoient parfois la même alerte plusieurs fois.
Impact utile: Une seule situation cohérente est conservée pour l’exploitation.
En cas de panne: L’état opérationnel devient incomplet; cette fonction ne prévient encore aucun humain à elle seule.
Responsable: Responsable de l’état local des alertes. Autorité de décision: Responsable des opérations.
Premiers gestes en cas de problème
Reconnaître ce qui se passe, protéger le service et prévenir le bon responsable sans improviser.
Première action sans risque
Vérifier l’heure du dernier état et les étapes juste avant et après. Un silence de supervision ne signifie jamais que tout va bien.
Solution de secours
L’équipe vérifie manuellement les étapes voisines. Les appels continuent seulement si leur chemin est indépendant; aucune notification humaine ne doit être supposée.
Qui prévenir et où lire les preuves
Responsable de l’état local des alertes. Autorité de décision: Responsable des opérations. La procédure de production reste à créer et valider avant la mise en service. Ouvrir la fiche d’architecture et de preuve du domaine.
Besoin d’un terme technique? Ouvrir les définitions
- Receiver
- terminaison de notification
- Deadman
- battement attestant que la supervision fonctionne
- EndsAt
- fin déclarée d’une alerte
Décision actuelle: mise en service interdite pour l’instant. Deux essais ont arrêté la première copie du programme qui regroupe les alertes, proprement puis brutalement, pendant que la seconde terminait le suivi. Un troisième a coupé seulement leur lien de coordination tout en gardant les deux copies actives. Le vrai service de réception a vu leurs envois en double, mais le stockage et les étapes suivantes n’ont conservé qu’un début de problème et une résolution. Les deux copies se sont ensuite retrouvées. Rien n’est déployé et aucune personne n’est prévenue. Ce qui reste à faire: Il reste à relier le vrai détecteur de pannes en amont, à répéter les bascules et d’autres coupures réseau, à démarrer les services comme en production, à prouver reprise, restauration, charge et délais, puis à brancher et tester la prise en charge humaine.Décision actuelle: promotion NO-GO, pas de mise en production. Deux exécutions indépendantes et identiques sont GREEN. Chacune verrouille 47 fichiers au digest 3a4d23bd20c1db25149babbe555f04baf959a4304cc4d200cc81df71cc671eb8; vérificateur 3/3, mutations 81/81, 1 425 contrôles exécutés, 846 uniques, 579 répétés et 31 scénarios. passes=2 désigne seulement l’arrêt contrôlé exit 0 et le crash SIGKILL exit 137 du sender. Une passe runtime isolée supplémentaire porte totalRuntimePasses à 3 et isolatedGossipPartitionScenarios à 1. Pendant cette partition, les deux Alertmanager 0.33.1 restent vivants, chacun voit seulement lui-même et expose cluster_members=1; leurs compteurs alertmanager_notifications_total avancent pour firing puis resolved. Le receiver observe les doublons physiques, mais la même génération ne garde qu’une transition durable firing et une resolved; outbox, Operations et sink convergent. B rejoint ensuite avec la même IP, le pairage redevient exactement 2 et cluster_members=2. Les deux scénarios de panne gardent duplicate_count=0; deux signaux et un échec enfant laissent zéro résidu. Cela prouve deux failovers bornés et une partition gossip isolée, pas une garantie générale d’une notification unique. Alertmanager reste at-least-once et fail-open. Autres partitions, répétitions, Prometheus réel, production, cloud, PSTN, systemd, humain, restauration, charge et SLO ne sont pas prouvés. Blockers: Prometheus réel dans le parcours complet, unités de production et boot systemd PID1, réplication receiver, sauvegarde/restauration souveraines, récupération opérateur de la DLQ, PostgreSQL HA, consumer operator-primary, notification humaine, charge, SLO et approbation restent à prouver.
État durable, séquence et modes dégradés
Owner: SRE/astreinte. Non-rôle: aucune alerte sortante, aucun ticket, aucun appel téléphonique et aucune décision carrier.
| Nominal | État / données | Panne / reprise | Observabilité / SLO |
|---|---|---|---|
Valide le webhook, ouvre BEGIN IMMEDIATE, classe nouveau/duplicate/resolved/ignoré, met à jour SQLite et place la transition éligible dans l’outbox interne attachée avant de remplacer atomiquement le snapshot. Le deadman n’entre pas dans cette outbox. | Digests de fingerprint/payload, code revu, enum d’état, timestamps bornés et compteurs; rétention 7 jours, 10 000 lignes max, fichiers 0600. L’outbox Operations reste un fichier interne distinct; le bridge ne doit pas recevoir un accès direct présumé. | Retry identique dédupliqué; firing après resolved ignoré; génération obsolète ignorée. La preuve complète perd une réponse après engagement, redémarre le vrai receiver puis rejoue sans second effet. Avant tout bootstrap du bridge, le preflight doit confirmer zéro incident firing actif; sinon l’upgrade est refusé ou rollbacké. | Snapshot rafraîchi toutes les 30 s; deadman stale après 180 s. Aucun SLO de livraison ou d’acquittement. |
Panne, reprise et surveillance
Modes de panne connus, comportement de reprise et signaux à mesurer avant toute mise en service.
| Modes de panne | Reprise après incident | Signaux à mesurer |
|---|---|---|
| L’état durable tient dans un SQLite local: rétention sept jours, dix mille lignes, fichiers 0600; aucune réplication ni restauration n’est prouvée. Le preflight refuse le bootstrap du bridge tant qu’un incident firing est actif. Le lab prouve crash après engagement, redémarrage et rejeu sans second effet; la restauration après perte du stockage reste absente. | Existent: snapshot rafraîchi toutes les 30 secondes, watchdog deadman content-free devenu stale après 180 secondes, et labs 23/23 et 12/12. N’existent pas: métriques de production ni SLO de livraison ou d’acquittement. Avant promotion, mesurer fraîcheur du deadman, taux de doublons et délais de convergence. |
Déplier ou replier les détails d’architecture
Interfaces, dépendances et déploiement
Le receiver est la terminaison de notification, distincte du collecteur de telemetry et des Alertmanager.
| Entrées | Sorties | Dépendances | Configuration |
|---|---|---|---|
POST /v1/alerts mTLS. passes=2 couvre arrêt contrôlé puis SIGKILL du sender. Une passe isolée envoie firing puis resolved depuis A et B restés vivants mais séparés sur le gossip. Le client brut reste négatif/chaos. | SQLite, snapshot et outbox atomique. Les deux pannes gardent duplicate_count=0. Pendant la partition, les doublons physiques sont observés mais une seule transition durable firing et une resolved sont conservées; l’aval converge. | Alertmanager A/B, CA notification, horloge, stockage local et bridge candidat. Le broker Unix isole le bridge des fichiers du receiver. | Bind cible 10.72.40.60:9444, 8 workers + 16 requêtes en file, timeout 5 s, service non privilégié et réseau privé. Aucun module cloud. |
Sources dépôt: infra/telephony/edge-health-receiver/receiver.py, unité systemd, config exacte, README et lab/run.py. Preuve: registre des preuves.
Frontière de confiance: Privé, plan management: le receiver termine le webhook mTLS des deux Alertmanager, lie certificat, SAN, EKU et adresse source au rôle attendu, et n’expose aucune sortie vers l’extérieur. Son écriture locale alimente un broker Unix isolé vers le bridge; aucun humain ni service public n’est contacté.
Déplier ou replier les détails de sécurité et de preuve
Contrat mTLS, sécurité et preuve hostile
Le serveur lie certificat, SAN, EKU et adresse source au rôle attendu.
| Identité | Garde | Preuve finale | Blockers |
|---|---|---|---|
| CA dédiée; SAN A/B et adresses source exactes. Le lab refuse un EKU client hostile. | Le lab isolé 23/23 refuse les schémas legacy/affaibli, borne EndsAt, vérifie firing et resolved idempotents, refuse un snapshot obsolète et garde le watchdog deadman actif. Le lab intégré 12/12 reste acquis. | Deux runs indépendants: 47 fichiers au digest 3a4d23bd20c1db25149babbe555f04baf959a4304cc4d200cc81df71cc671eb8, 3/3, 81/81, 1 425/846/579 et 31 scénarios. passes=2; totalRuntimePasses=3. Pendant la partition, A/B restent vivants à cluster_members=1; les doublons physiques convergent vers un firing et un resolved durables. Reconnexion B même IP et cluster_members=2. | Autres partitions, répétitions et garantie générale de notification unique; Prometheus réel, production, réplication receiver, restauration, humain, charge et SLO. Promotion NO-GO. |
| Données et souveraineté UE | Le receiver stocke des digests, codes bornés, états et timestamps, sans contenu d’appel: tout vit dans un SQLite local sur la machine privée. Aucune sortie vers un tiers n’existe; le seul relais prévu reste interne. Réplication, sauvegarde et résidence UE ne sont pas prouvées. | ||