VIP management
L’exporter edge continue vers 10.72.40.50:9443.
Statut:code + validations localescluster non démarrénotification non livréepromotion NO-GO
Flux privé candidat, sans changement de l’exporter
Le lot reste hors chemin d’appel. Chaque étape ci-dessous décrit une configuration candidate, pas un service actif.
TCP passthrough
Load balancer Scaleway privé, sans Proxy Protocol, avec health check TCP.
Ingestion et métriques
10.72.41.10:9443 et 10.72.42.10:9443 reçoivent l’export et exposent GET /metrics.
Agrégation directe
Chaque configuration cible les deux collecteurs, agrège par cellule et scope, puis adresse les deux Alertmanager sans LB.
Webhook privé
Les deux Alertmanager ciblent directement 10.72.40.60:9444/v1/alerts.
Interfaces et frontières de confiance
Le plan management reste privé. Le passthrough conserve l’identité edge jusqu’au collecteur, mais ne prouve pas l’adresse source backend du LB.
| Canal | Contrat | Identité / garde | Limite |
|---|---|---|---|
| Exporter vers collecteur | mTLS TCP/9443 via VIP; TLS transmis sans terminaison ni Proxy Protocol | Identités télémétrie edge A/B déjà définies | CIDR source réel du backend LB non mesuré; health check TCP non sémantique |
| Prometheus vers métriques | GET /metrics direct sur chaque collecteur | prometheus-a.monitoring.navy.invalid ou prometheus-b.monitoring.navy.invalid; rôles monitoring et télémétrie non interchangeables | Aucun scrape runtime ni certificat de production |
| Prometheus vers Alertmanager | Chaque Prometheus adresse directement A et B, jamais un LB | mTLS monitoring, vérification TLS non désactivable | Aucun cluster démarré |
| Gossip Alertmanager | mTLS privé sur 9094 entre A et B | Certificats A/B et CA cluster dédiés | Partition et convergence runtime non exercées |
| Notification | Webhook mTLS privé; send_resolved=true; max_alerts=16; proxy et redirection refusés | Identité Alertmanager vers récepteur exploitation | Aucune livraison, idempotence ou reconnaissance opérateur prouvée |
Sémantique HA et notification
La redondance visée réduit les vues partielles, sans promettre une livraison exactement une fois.
Deux vues par cellule
Prometheus 3.14.0, verrouillé par digest OCI, cible les collecteurs A et B. Les règles agrègent par cellule et scope avant de conclure à une absence ou une indisponibilité.
Doublons possibles
Alertmanager 0.33.1, également verrouillé par digest, privilégie la disponibilité. Une partition du gossip peut produire des notifications en double; le récepteur doit donc fournir une idempotence prouvée.
Cette page possède l’acheminement HA et la notification. Les cinq alertes calculées localement restent décrites par le collecteur; les SLO et runbooks restent dans Observabilité et SLO.
Preuve acquise et blockers
La validation locale porte sur les artefacts. Elle ne constitue ni une recette HA, ni une notification d’astreinte.
| Acquis local | Blocker de promotion |
|---|---|
Règles et scénarios promtool; configurations Prometheus, Alertmanager et web mTLS; arguments binaires; versions et digests OCI. | alerting-runtime-ha-not-proven, private-lb-not-deployed, load-balancer-backend-source-address-not-proven |
| Topologie privée, routage direct A/B, inhibition et limites de livraison vérifiés statiquement; aucun cluster runtime démarré. | notification-delivery-not-proven, receiver-idempotency-not-proven, operator-acknowledgement-not-proven |