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é.
État réel:Prometheus 3.14.0 digest-pinnédeux runtimes locauxdeux scrapes par Prometheuslab 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 lecteur régulier de métriques qui transforme des mesures en alertes candidates.
Ce qu’il faut retenir
Ce que c’est
Prometheus est un moteur qui vient chercher périodiquement des métriques et évalue des règles.
Pourquoi il existe
Pour comparer les vues des collecteurs A et B et distinguer une cellule malade d’un problème de supervision.
Qui en bénéficie
Les opérateurs, qui reçoivent des alertes agrégées plutôt qu’un flux de détails bruts.
Exemple concret
Dans le lab, chacun des deux Prometheus lit les deux collecteurs; une cellule not-ready produit ensuite un firing puis un resolved de bout en bout.
S’il tombe
La perte de Prometheus A a laissé B poursuivre le scénario local. Une panne double et la reprise en production 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 Prometheus souverain n’est déployé.
Scrape: lecture périodique d’un endpoint de métriques.TSDB: base de séries temporelles.promtool: outil de validation des règles Prometheus.
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
GET /metrics mTLS sur les collecteurs A/B.
Chaque Prometheus scrute directement les collecteurs A et B, puis envoie ses alertes aux deux Alertmanager.
Alertmanager A/B et vues 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étecter les cellules indisponibles avec deux observateurs indépendants. L’astreinte et les owners de la plateforme téléphonique.
Conséquence d’une panne: Ne passe jamais par le LB pour l’alerting et ne livre pas directement au receiver. Le mode dégradé détaillé reste visible dans le profil Opérations.
Mini-glossaire contextuel
Prometheus: moteur de métriques et règles. Scrape: lecture périodique de métriques. Règle: condition produisant une alerte.
Risques, blockers et état réel: le lab prouve des scrapes, la perte de Prometheus A et la continuité locale synthétique. Il ne prouve ni déploiement souverain, stockage TSDB durable, charge, SLO, astreinte ou carrier réel. Promotion NO-GO.
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. |
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.
Identités, trust boundary et souveraineté
Les identités monitoring ne peuvent pas se faire passer pour une cellule telemetry.
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.