Alertmanager A et B
SAN alertmanager-a.notification.navy.invalid et alertmanager-b.notification.navy.invalid; CA cluster séparée et quatre rôles croisés refusés dans le lab.
État réel:Alertmanager 0.33.1 digest-pinnédeux runtimes locauxgossip bilatérallab fermé 12/12NO-GO
Toutes les vues sont affichées. Les risques et le statut NO-GO restent toujours visibles.
En bref: comprendre en 60 secondes
Le répartiteur d’alertes qui évite de réveiller plusieurs fois l’équipe quand tout va bien, sans garantir exactement une livraison.
Ce qu’il faut retenir
Ce que c’est
Un service qui reçoit des alertes, les regroupe, les inhibe si nécessaire et les transmet à une destination.
Pourquoi il existe
Pour transformer des alertes techniques répétitives en notifications structurées et résolues.
Qui en bénéficie
L’équipe d’exploitation, qui obtient un flux plus cohérent et peut recevoir les résolutions.
Exemple concret
Dans le lab, une cellule not-ready produit un firing puis un resolved; le receiver déduplique les copies issues d’une partition fail-open.
S’il tombe
L’arrêt d’Alertmanager A a été exercé pendant le scénario. Une panne double, la restauration durable et la livraison humaine restent à qualifier.
Responsabilité humaine
L’équipe propriétaire indiquée dans la vue Opérations surveille ce composant, choisit le repli et autorise sa remise en service. Une personne reste responsable de toute décision ayant un effet sur un appel, un utilisateur ou une promotion.
Statut réel: prouvé ou envisagé
Code, configs et runtime-lab local 12/12 verts; aucun cluster souverain n’est déployé.
Fail-open: privilégie la disponibilité, au prix possible de doublons.Gossip: échange d’état entre réplicas.Inhibition: règle empêchant une alerte secondaire de notifier inutilement.
Lecture métier et trajet simple
Le flux montre ce qui arrive au composant, ce qu’il fait et à qui il transmet. Tout reste lisible sans JavaScript.
Suivre le flux
Prometheus A/B avec règles validées.
Chaque Prometheus envoie aux deux Alertmanager; chacun notifie directement le receiver privé.
Receiver privé mTLS et futur processus d’acquittement humain.
Légende: Avant = dépendance amont, centre = responsabilité de cette fiche, Après = consommateur aval. Le focus clavier surligne l’étape sans masquer les autres.
Étape 1 sur 3: dépendance amont.
Impact métier: Limiter le bruit tout en gardant deux chemins de notification disponibles. L’astreinte et les systèmes d’exploitation qui reçoivent les alertes.
Conséquence d’une panne: Ne garantit pas une seule livraison et ne passe jamais par le load balancer collecteur. Le mode dégradé détaillé reste visible dans le profil Opérations.
Mini-glossaire contextuel
Alertmanager: routeur d’alertes. Gossip: synchronisation entre pairs. Fail-open: privilégie la livraison, avec doublons possibles.
Risques, blockers et état réel: le lab prouve localement partition fail-open, doublons dédupliqués au receiver, guérison et arrêt d’Alertmanager A pendant un scénario not-ready. Il ne prouve ni déploiement souverain, notification humaine, réplication du receiver, restauration ou SLO. Promotion NO-GO.
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.
| Nominal | Dégradé | État | Observabilité / SLO |
|---|---|---|---|
A et B reçoivent les alertes, échangent leur gossip bilatéral, groupent puis envoient directement au receiver avec send_resolved=true et max_alerts=16; aucun faux incident au nominal. | Alertmanager A arrêté pendant un not-ready E2E; partition fail-open, doublons dédupliqués et guérison exercés; panne receiver puis retry exercés. | État cluster et notifications éphémères du lab nettoyés; aucune persistance, sauvegarde ou restauration qualifiée. | Le lab vérifie les scénarios, pas un délai de notification, une disponibilité ou une capacité contractuelle. |
Interfaces, dépendances et configuration
Les deux Prometheus adressent directement les deux Alertmanager; aucun LB ne masque la topologie.
| Entrées | Sorties | Cluster | Dépendances |
|---|---|---|---|
| Alertes de Prometheus A/B sur interfaces privées mTLS. | HTTPS mTLS direct vers 10.72.40.60:9444; proxy et redirection refusés. | Gossip privé mTLS sur TCP/9094 entre A et B exercé bilatéralement dans le lab fermé. | DNS/PKI monitoring et notification, règles de routage, receiver et réseau management. |
Sources dépôt: infra/telephony/edge-health-alerting/alertmanager-*.yml, arguments A/B, validations et runtime-lab fermé. Risque: registre des risques.
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.
Interop et secrets non opérés
Certificats de production, rotation/révocation, cluster souverain, sauvegarde/restauration et livraison humaine restent ouverts.