Toutes les vues sont affichées. Les risques et le statut NO-GO restent toujours visibles.
En bref: comprendre en 60 secondes
La boîte de réception privée qui refuse les messages ambigus et se souvient des alertes déjà vues.
Ce qu’il faut retenir
Un serveur HTTPS privé qui reçoit les webhooks d’Alertmanager et conserve uniquement un état borné et sans contenu d’appel.
Pour dédupliquer les retries, suivre firing puis resolved, et détecter l’absence totale de battement de supervision.
L’exploitation, qui obtient un état durable avant de brancher une future chaîne d’acquittement humaine.
Pendant une partition du lab, deux notifications identiques arrivent; le receiver les déduplique, puis observe la résolution après guérison.
La panne puis le retry ont été exercés localement, mais aucun second receiver ne reprend et aucune action humaine n’est garantie.
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.
Labs locaux 23/23 isolé et 12/12 intégré verts; aucun déploiement, failover receiver ou notification humaine.
Webhook: requête HTTP envoyée automatiquement lors d’un événement.Deadman: battement attendu; son absence signale que la supervision peut être muette.Idempotence: répéter le même message ne crée pas un nouvel effet.
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
Alertmanager A/B sur le réseau notification privé.
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.
SQLite, snapshot content-free et futur consommateur d’exploitation.
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: Dédupliquer les retries, suivre firing/résolu et rendre visible un silence total de supervision. L’exploitation, avant branchement d’une future chaîne humaine d’acquittement.
Conséquence d’une panne: N’envoie aucun ticket, appel ou message d’astreinte et ne prend aucune décision carrier. Le mode dégradé détaillé reste visible dans le profil Opérations.
Mini-glossaire contextuel
Receiver: terminaison de notification. Deadman: battement attestant que la supervision fonctionne. EndsAt: fin déclarée d’une alerte.
Risques, blockers et état réel: idempotence, retry, firing vers resolved, doublons de partition et deadman sont prouvés avec deux Alertmanager réels dans le lab. Le receiver reste unique, non déployé, sans restauration ni chemin d’acquittement ou d’escalade humaine. Promotion NO-GO.
É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 puis remplace atomiquement le snapshot. | Digests de fingerprint/payload, code revu, enum d’état, timestamps bornés et compteurs; rétention 7 jours, 10 000 lignes max, fichiers 0600. | Retry identique dédupliqué; firing après resolved ignoré; génération obsolète ignorée. Pas de réplication, backup/restauration ni bascule. | Snapshot rafraîchi toutes les 30 s; deadman stale après 180 s. Aucun SLO de livraison ou d’acquittement. |
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 avec schéma webhook v4, maximum 16 alertes et truncatedAlerts=0; POST /v1/deadman avec exactement un firing deadman. | Réponse JSON bornée, SQLite receiver.sqlite3 et snapshot.json; aucun appel réseau sortant. | Alertmanager A/B, CA notification dédiée, horloge et stockage local systemd. | 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.
Contrat mTLS, sécurité et preuve hostile
Le serveur lie simultanément certificat, SAN, EKU et adresse source au rôle Alertmanager attendu.
| Identité / trust boundary | Garde applicative | Preuve locale | Blockers |
|---|---|---|---|
CA notification dédiée; SAN client exact A ou B lié à 10.72.41.20/32 ou 10.72.42.20/32; SAN serveur operations-alerts.monitoring.navy.invalid. | JSON sans clés dupliquées, méthode/route/content-type/content-length exacts, labels et annotations fermés; aucun payload, certificat, numéro, transcript ou donnée SIP loggé. | Le lab isolé 23/23 refuse les schémas legacy/affaibli, le snapshot obsolète et l’EKU client hostile; il vérifie firing et resolved idempotents et le watchdog deadman actif. Le lab intégré 12/12 ajoute deux Alertmanager réels, panne receiver puis retry, doublons de partition dédupliqués et deadman stale à 180 s. | Déploiement souverain, réplication receiver, sauvegarde/restauration, livraison humaine, acquittement, escalade et SLO. |