Symptôme visible
Les alertes peuvent être retardées, répétées ou perdues; les deux chemins doivent être surveillés.
État réel:Alertmanager 0.33.1 digest-pinnédeux runtimes locauxgossip bilatérallab fermé 12/12NO-GO
Quel est votre profil?
Comment choisir ma vue?
Direction ou métier: valeur, bénéficiaires, résultat, dépendances, panne et responsabilité. Opérations ou support: symptômes, première action, repli et escalade. Architecte ou ingénieur: protocoles, ports, configuration, données, tests et preuves.
Vue Direction / métier affichée. Ce choix sera repris sur les autres fiches. Les risques et le statut NO-GO restent toujours visibles.
En clair: comprendre en 60 secondes
Aucun bagage technique n’est nécessaire pour lire cette vue.
Ce qu’il faut retenir
Ce que c’est
Regrouper et transmettre les alertes. C’est une partie distincte de Navy Phone.
À quoi ça sert
Limiter les doublons et transmettre les alertes par deux chemins indépendants.
Qui en bénéficie
Les personnes qui appellent et l’équipe chargée de détecter puis traiter les pannes.
Situation déclenchante
Une ou deux sources signalent le même problème.
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é.
Résultat observable
L’alerte utile est regroupée puis envoyée au service qui la conserve.
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.
Que se passe-t-il en panne?
Les alertes peuvent être retardées, répétées ou perdues; les deux chemins doivent être surveillés.
Repli et intervention manuelle
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.
Responsable au quotidien
L’équipe d’exploitation téléphonique surveille ce composant et décide du repli.
Statut réel
Des essais limités sur une machine ont réussi. Ils ne prouvent pas que le service fonctionne dans le cloud, sur le réseau téléphonique réel ou en production. Décision actuelle: promotion NO-GO, pas de mise en production.
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
Composant documenté: Alertmanager A/B edge-health.
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: un besoin arrive, cette partie du système rend un service précis, puis une personne ou une équipe en bénéficie. Les noms de protocoles restent dans la vue Architecte.
Étape 1 sur 3: le besoin auquel le composant répond.
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: L’équipe d’exploitation téléphonique surveille ce composant et décide du repli.
Aide Opérations / support
Reconnaître le symptôme, protéger le service et transmettre au bon responsable sans improviser.
Première action sûre
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.
Repli manuel
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.
Escalade et runbook
L’équipe d’exploitation téléphonique surveille ce composant et décide du repli. Le runbook de production reste à valider avant mise en service. Ouvrir le document de référence.
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: promotion NO-GO, pas de mise en production. Des essais limités sur une machine ont réussi. Ils ne prouvent pas que le service fonctionne dans le cloud, sur le réseau téléphonique réel ou en production. Ce qui manque: Il reste à le déployer, à tester de vraies pannes, à mesurer sa fiabilité et à vérifier les services externes.
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. |
Déplier ou replier les détails d’architecture
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.
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.
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.
Interop et secrets non opérés
Certificats de production, rotation/révocation, cluster souverain, sauvegarde/restauration et livraison humaine restent ouverts.