Symptôme visible
Une panne peut ne plus être détectée par ce chemin; l’absence de supervision doit elle-même devenir visible.
État réel:Prometheus 3.14.0 digest-pinnédeux runtimes locauxdeux scrapes par Prometheuslab 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
Détecter les problèmes de santé. C’est une partie distincte de Navy Phone.
À quoi ça sert
Observer les bilans depuis deux points indépendants et déclencher une alerte quand une cellule semble indisponible.
Qui en bénéficie
Les personnes qui appellent et l’équipe chargée de détecter puis traiter les pannes.
Situation déclenchante
Les collecteurs publient les dernières mesures de santé.
Exemple concret
Les collecteurs publient les dernières mesures de santé. Une anomalie produit une alerte par deux chemins séparés.
Voir l’exemple technique précis
Chaque Prometheus scrute directement les collecteurs A et B, puis envoie ses alertes aux deux Alertmanager.
Résultat observable
Une anomalie produit une alerte par deux chemins séparés.
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?
Une panne peut ne plus être détectée par ce chemin; l’absence de supervision doit elle-même devenir visible.
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é: Prometheus A/B edge-health.
Les collecteurs publient les dernières mesures de santé.
Observer les bilans depuis deux points indépendants et déclencher une alerte quand une cellule semble indisponible.
Une anomalie produit une alerte par deux chemins séparés.
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: Une anomalie produit une alerte par deux chemins séparés.
En cas de panne: Une panne peut ne plus être détectée par ce chemin; l’absence de supervision doit elle-même devenir visible.
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
- Prometheus
- moteur de métriques et règles
- Scrape
- lecture périodique de métriques
- Règle
- condition produisant une alerte
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.
Règles, panne et observabilité
Owner cible: SRE observabilité. Non-rôle: aucune ingestion d’enveloppe, aucun stockage d’appel et aucun envoi direct à l’astreinte.
| Nominal | Dégradé | État | SLO |
|---|---|---|---|
Deux Prometheus réels scrutent chacun A et B, soit deux scrapes par Prometheus, agrègent par cell/scope, évaluent les règles et envoient à Alertmanager A et B. | Perte de Prometheus A exercée; perte simple puis double des collecteurs et reprise exercées; aucun faux incident au nominal. | TSDB éphémère du lab nettoyée. Rétention, sauvegarde et données de production restent à figer. | Le lab vérifie le comportement, pas une disponibilité, une capacité ou un délai contractuel. |
Déplier ou replier les détails d’architecture
Interfaces, dépendances et déploiement
Les scrapes ne passent pas par la VIP d’ingestion; chaque Prometheus adresse directement les deux collecteurs.
| Entrées | Sorties | Dépendances | Configuration |
|---|---|---|---|
GET /metrics mTLS sur collecteur A et B; sept endpoints mTLS existent dans le lab complet. | Alertes vers Alertmanager A et B, directement et jamais via LB. | DNS privé, PKI monitoring, règles edge-health et deux collecteurs. | Prometheus 3.14.0 digest-pinné, fichiers A/B et web mTLS exercés dans le lab; aucun module de déploiement ni volume qualifié. |
Sources dépôt: infra/telephony/edge-health-alerting/prometheus-*.yml, règles, scénarios promtool et runtime-lab fermé. Statut: registre des preuves.
Déplier ou replier les détails de sécurité et de preuve
Identités, trust boundary et souveraineté
Les identités monitoring ne peuvent pas se faire passer pour une cellule telemetry.
Prometheus A/B distincts
Identités prometheus-a.monitoring.navy.invalid et prometheus-b.monitoring.navy.invalid; quatre rôles croisés sont refusés dans le lab fermé.
Secrets et résidence non opérés
Certificats de production, rotation, stockage TSDB, RBAC, rétention, chiffrement disque et déploiement souverain restent à prouver.