Ce que vous voyez
Les alertes peuvent être retardées, répétées ou perdues; les deux chemins doivent être surveillés.
État d’avancement:Programme réel testé localementfiche de référencemise en service interdite pour l’instantÉtat réel:Alertmanager 0.33.1 A/B réelspasses=2 + partition isoléetotalRuntimePasses=3NO-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
Regrouper et transmettre les alertes.
Limiter les doublons et transmettre les alertes par deux chemins indépendants.
Une comparaison utile
Comme un standard: il regroupe les signalements d’un même incident.
Ce qui entre
Une ou deux sources signalent le même problème.
Qui en bénéficie et quel résultat attendre
L’alerte utile est regroupée puis envoyée au service qui la conserve.
L’équipe chargée de détecter et traiter les pannes.
État actuel
Programme réel testé localement. Deux essais ont arrêté une copie, proprement puis brutalement. Un troisième a isolé le lien entre les deux copies actives: chacune a envoyé, mais une seule suite durable a été conservée. Production et notification unique générale restent à prouver. Mise en service interdite pour l’instant.
Risque principal
Les alertes peuvent être retardées, répétées ou perdues; les deux chemins doivent être surveillés.
Responsable
Responsable du regroupement des alertes. Autorité de décision: Responsable des opérations.
Décision suivante
Autoriser le routage quand deux chemins indépendants produisent une seule alerte utile sans masquer une panne.
Voir les dépendances, preuves et solutions de secours
Ce qui entre, en langage courant
Une ou deux sources signalent le même problème.
Ce dont il dépend
Des bilans de santé récents, du réseau privé et des étapes voisines de la chaîne d’alerte.
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
Deux relais regroupent les signalements. Si l’un s’arrête, l’autre finit le travail. Si leur lien de coordination est coupé, chacun envoie de son côté et des copies arrivent en double; le registre final n’en garde qu’une. Rien ne quitte le réseau privé et personne n’est prévenu.
Preuve attendue avant la prochaine étape
Essais de doublons, silence d’un chemin, répétition, résolution et panne successive des deux services.
Statut expliqué
Deux essais complets et identiques 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 essai a gardé les deux copies actives mais a coupé seulement leur lien de coordination: chacune a envoyé le problème puis sa résolution. Le service de réception a vu les copies physiques, mais une seule suite durable a été conservée. Le lien a été rétabli et les deux copies se sont retrouvées. Cela reste un essai local, sans garantie générale d’un seul envoi. Il reste à relier le vrai détecteur de pannes, à répéter les bascules et d’autres coupures réseau, à déployer et redémarrer les services comme en production, à prouver restauration, charge et délais, puis à brancher et tester la prise en charge humaine.
Exemple concret
Une ou deux sources signalent le même problème. L’alerte utile est regroupée puis envoyée au service qui la conserve.
Voir l’exemple technique précis
Chaque Prometheus envoie aux deux Alertmanager; chacun notifie directement le receiver privé.
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 complets et identiques 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 essai a gardé les deux copies actives mais a coupé seulement leur lien de coordination: chacune a envoyé le problème puis sa résolution. Le service de réception a vu les copies physiques, mais une seule suite durable a été conservée. Le lien a été rétabli et les deux copies se sont retrouvées. Cela reste un essai local, sans garantie générale d’un seul envoi. Autoriser le routage quand deux chemins indépendants produisent une seule alerte utile sans masquer une panne. - Métier
- Question: Quel service rend-elle concrètement?
Réponse: Limiter les doublons et transmettre les alertes par deux chemins indépendants. L’alerte utile est regroupée puis envoyée au service qui la conserve. - Achats et conformité
- Question: De quoi dépend l’engagement et qu’est-ce qui manque?
Réponse: Des bilans de santé récents, du réseau privé et des étapes voisines de la chaîne d’alerte. Il reste à relier le vrai détecteur de pannes, à répéter les bascules et d’autres coupures réseau, à déployer et redémarrer les services comme en production, à prouver restauration, charge et délais, puis à brancher et tester la prise en charge humaine. Preuve attendue: Essais de doublons, silence d’un chemin, répétition, résolution et panne successive des deux services. - Communication
- Question: Que peut-on annoncer sans faire de fausse promesse?
Réponse: Vous pouvez expliquer l’objectif suivant: Limiter les doublons et transmettre les alertes par deux chemins indépendants. Ne présentez pas cette fonction comme disponible en production: Deux essais complets et identiques 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 essai a gardé les deux copies actives mais a coupé seulement leur lien de coordination: chacune a envoyé le problème puis sa résolution. Le service de réception a vu les copies physiques, mais une seule suite durable a été conservée. Le lien a été rétabli et les deux copies se sont retrouvées. Cela reste un essai local, sans garantie générale d’un seul envoi. - Exploitation
- Question: Qui agit et quel est le premier geste sans risque?
Réponse: Responsable du regroupement 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: Regrouper et transmettre les alertes.
Une ou deux sources signalent le même problème.
Limiter les doublons et transmettre les alertes par deux chemins indépendants.
L’alerte utile est regroupée puis envoyée au service qui la conserve.
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: Une ou deux sources signalent le même problème.
Impact utile: L’alerte utile est regroupée puis envoyée au service qui la conserve.
En cas de panne: Les alertes peuvent être retardées, répétées ou perdues; les deux chemins doivent être surveillés.
Responsable: Responsable du regroupement 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 du regroupement 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
- Alertmanager
- routeur d’alertes
- Gossip
- synchronisation entre pairs
- Fail-open
- privilégie la livraison, avec doublons possibles
Décision actuelle: mise en service interdite pour l’instant. Deux essais complets et identiques 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 essai a gardé les deux copies actives mais a coupé seulement leur lien de coordination: chacune a envoyé le problème puis sa résolution. Le service de réception a vu les copies physiques, mais une seule suite durable a été conservée. Le lien a été rétabli et les deux copies se sont retrouvées. Cela reste un essai local, sans garantie générale d’un seul envoi. Ce qui reste à faire: Il reste à relier le vrai détecteur de pannes, à répéter les bascules et d’autres coupures réseau, à déployer et redémarrer les services comme en production, à prouver 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; le vérificateur passe 3/3, les mutations 81/81, et 1 425 contrôles sont exécutés, dont 846 uniques et 579 répétés, sur 31 scénarios. passes=2 désigne uniquement les deux passes nominales de panne: arrêt contrôlé exit 0 puis crash SIGKILL exit 137 du sender réel dérivé de peer_sha256. Dans les deux, le survivor reçoit seul le resolved de même génération, duplicate_count=0, et l’aval converge. Une passe runtime isolée supplémentaire porte totalRuntimePasses à 3 et isolatedGossipPartitionScenarios à 1. Les deux Alertmanager 0.33.1 restent vivants mais perdent seulement leur réseau gossip; chacun ne voit que lui-même et expose cluster_members=1. Les compteurs alertmanager_notifications_total de A et B avancent pour firing puis resolved. Le receiver observe les doublons physiques, tandis que receiver, outbox, Operations et sink ne conservent qu’une transition durable firing et une resolved. B rejoint ensuite le pairage avec la même IP; chacun voit exactement deux pairs et cluster_members=2. Deux signaux et un échec enfant laissent zéro résidu. Ces essais prouvent localement deux failovers bornés et une partition gossip isolée avec convergence durable. Ils ne prouvent ni les répétitions, ni les autres partitions, ni une garantie générale d’une notification unique. Alertmanager reste at-least-once et fail-open. Prometheus réel, production, cloud, PSTN, appel téléphonique, systemd, charge, SLO et humain restent faux ou non exercés. Promotion NO-GO. Blockers: Autres partitions, failovers répétés et garantie générale d’une seule notification; Prometheus réel dans le parcours complet; déploiement souverain A/B, PKI et secrets opérés, unités de production et boot systemd PID1, sauvegarde/restauration, charge, SLO, notification et acquittement humains restent à prouver.
Routage, panne et exploitation
Owner cible: SRE/astreinte. Non-rôle: aucune décision sur l’appel, aucune conservation d’audio et aucun acquittement humain.
| Deux arrêts bornés | Lien de coordination isolé | Retour | Limite |
|---|---|---|---|
passes=2: le sender sort avec exit 0 après arrêt contrôlé puis exit 137 après SIGKILL. Dans les deux, le survivor reçoit seul le resolved, le receiver garde duplicate_count=0 et l’aval converge. | Une passe runtime supplémentaire garde A et B vivants mais coupe seulement le gossip. Chacun voit un membre, expose cluster_members=1 et notifie firing puis resolved. Le receiver voit les doublons physiques; la chaîne ne garde qu’un firing et un resolved durables. | B rejoint avec la même IP. Chaque pair voit exactement deux membres et cluster_members=2. Les deux runs indépendants sont identiques, soit 1 425 contrôles exécutés, 846 uniques, 579 répétés et 31 scénarios par run. | Alertmanager reste at-least-once et fail-open. Autres partitions, répétitions, garantie générale de notification unique, production, charge et SLO ne sont pas prouvés. |
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 de cluster est reconstruit par gossip: au retour du pair avec la même adresse, le membership redevient exactement deux. Aucune donnée métier n’est conservée. Le lab prouve deux arrêts puis une partition isolée, avec convergence durable; autres partitions, répétitions et restauration générale ne sont pas prouvées, et aucune action humaine n’est requise ni définie. | Existent: compteurs alertmanager_notifications_total, cluster_members, et le lab de 1 425 contrôles sur 31 scénarios verrouillés par digest, exécuté deux fois à l’identique. N’existent pas: déploiement, charge ni SLO. Avant promotion, mesurer délais de notification, taux de doublons et comportement sous d’autres partitions. |
Déplier ou replier les détails d’architecture
Interfaces, dépendances et configuration
Le stimulus reste une API synthétique; Prometheus réel n’est pas lancé dans ce parcours.
| Entrées | Sorties | Partition et guérison | Dépendances |
|---|---|---|---|
Firing vers les deux /api/v2/alerts; resolved sur le survivor pour les deux pannes. Pendant la partition isolée, firing puis resolved vers A et B. | Webhooks HTTPS mTLS créés par Alertmanager vers le receiver. Les compteurs alertmanager_notifications_total de A et B avancent pour les deux phases. | Gossip seul coupé, processus vivants, membership exact 1 et cluster_members=1. Reconnexion B avec même IP, membership exact 2 et cluster_members=2. | DNS/PKI monitoring et notification, receiver et réseau management. Alertmanager reste at-least-once et fail-open. realPrometheusProcessExercised=false; production, cloud, PSTN, humain et systemd restent faux. |
47 fichiers au digest 3a4d23bd20c1db25149babbe555f04baf959a4304cc4d200cc81df71cc671eb8; vérificateur 3/3 et mutations 81/81. passes=2, totalRuntimePasses=3, isolatedGossipPartitionScenarios=1. Risque: registre des risques.
Frontière de confiance: Privé, plan management: les deux Alertmanager reçoivent les alertes des Prometheus sur une route mTLS monitoring et notifient le receiver par HTTPS mTLS avec une autorité de certification de notification dédiée. Rien ne sort vers un canal humain ou public; le passage est contrôlé par identités distinctes, jamais par une identité telemetry.
Déplier ou replier les détails de sécurité et de preuve
Identités, sécurité et données
La CA de notification est dédiée; une identité telemetry ou monitoring ne doit pas être acceptée comme émetteur de webhook.
Deux runs identiques
Chaque run est GREEN: 1 425 contrôles exécutés, 846 uniques, 579 répétés, 31 scénarios, passes=2 et totalRuntimePasses=3; vérificateur 3/3 et mutations 81/81 sur le digest 3a4d23bd20c1db25149babbe555f04baf959a4304cc4d200cc81df71cc671eb8.
Promotion inchangée
Deux failovers bornés et une partition gossip isolée avec convergence durable sont prouvés localement. Autres partitions, répétitions et garantie générale d’une notification unique ne le sont pas. Prometheus réel, production, systemd, cloud, PSTN, humain, charge, SLO, sauvegarde et restauration restent ouverts. Promotion NO-GO.
| Données et souveraineté UE | Les alertes sont des événements techniques content-free sans contenu d’appel, échangées entre services privés du plan management. Aucune sortie vers un tiers ni canal humain n’existe: le chemin d’astreinte reste à construire. La résidence des données n’est pas prouvée, aucun déploiement souverain n’est attesté. | ||
|---|---|---|---|