Ce que c’est
Système de collecte et d’interrogation de métriques.
Ce qu’on y travaille dans le laboratoire
- ·Mesurer taux d’erreur, latence et débit
- ·Définir des seuils d’alerte pertinents
- ·Distinguer une panne d’une dégradation
Parcours de maîtrise
Six blocs, vingt laboratoires — de l’installation de la collecte à un observatoire des rails de paiement restituable en comité.
Niveau 1 · Labs 1 à 3 · Bloc 1
Fondations
Installer la collecte et exposer les premières mesures.
- Notions de supervision : cible, collecte, série temporelle
- Installation du collecteur et de l’outil de visualisation
- Exportateurs d’infrastructure : système, base de données, cache
- Première série de métriques exploitables
Niveau 2 · Labs 4 à 6 · Bloc 2
Collecte et interrogation
Maîtriser le langage d’interrogation, qui est le vrai sujet.
- Sélecteurs, fonctions, agrégations, fenêtres temporelles
- Métriques de paiement : volume, durée, montant, opérations en cours
- Calcul d’un taux de succès par participant
- Règles d’enregistrement pour les calculs coûteux
Niveau 3 · Labs 7 à 11 · Bloc 3
Observabilité des paiements
Instrumenter la chaîne, rail par rail.
- Tableau de bord des opérations de paiement
- Supervision de la monétique et des codes réponse
- Supervision de la messagerie normalisée
- Supervision du connecteur de paiement instantané
Niveau 4 · Labs 12 à 14 · Bloc 4
Fiabilité et plateforme
Passer de la mesure à l’engagement de service.
- Alertes de paiement et acheminement des notifications
- Indicateurs et objectifs de service, budget d’erreur
- Supervision de l’orchestration de conteneurs
- Distinguer dégradation applicative, réseau, base de données et infrastructure
Niveau 5 · Labs 15 à 18 · Bloc 5
Pile d’observabilité
Relier les trois signaux.
- Exemplaires : passer d’une métrique à la trace correspondante
- Traçage distribué d’un paiement
- Corrélation métriques, journaux et traces dans une même vue
- Supervision du registre financier
Niveau 6 · Labs 19 et 20 · Bloc 6
Expert et métier
Restituer à la direction, pas seulement à l’exploitation.
- Tableaux de bord de la plateforme d’intégration et de la couche de services
- Observatoire des rails : disponibilité, latence, taux de succès par rail
- Vision multi-participants et haute disponibilité de la supervision
- Projet final : plateforme d’observabilité des paiements
Le parcours se valide sur preuve. Chaque niveau se franchit par une démonstration en conditions réelles devant un jury, avec un critère d’acceptation écrit à l’avance — la règle de la Méthode SAKITI appliquée au laboratoire.
Les questions auxquelles la supervision doit répondre
Ce ne sont pas des questions techniques : ce sont celles que pose une direction un jour d’incident. Une plateforme d’observabilité se juge à sa capacité d’y répondre en quelques minutes.
- 01Combien de transactions sont traitées, et à quel rythme ?
- 02Quel est le taux de succès, et pour quelles banques se dégrade-t-il ?
- 03Quel rail est dégradé ? Quelles transactions expirent ?
- 04Quelle est la latence aux 50e, 95e et 99e centiles ?
- 05Les comptes sont-ils équilibrés ? Un connecteur est-il indisponible ?
- 06La dégradation est-elle applicative, réseau, base de données ou infrastructure ?
Les métriques de paiement de référence
Une base commune à tous les laboratoires. Nommées une fois, elles se comparent d’un composant à l’autre.
- 01Transactions : total, durée, montant, opérations en cours
- 02Décisions : autorisations, refus
- 03Incidents : expirations, annulations, remboursements
Les étiquettes qui rendent une métrique exploitable
Sans elles, un compteur ne dit rien. Avec elles, il répond aux six questions ci-dessus.
Le tableau de bord des opérations
Quatre chiffres en tête de page, et trois vues en dessous. C’est le livrable du septième laboratoire, et le seul écran qu’une direction regardera vraiment.
| Élément | Ce qu’il montre |
|---|---|
| Débit transactionnel | Le rythme réel, comparé à la période précédente |
| Taux de succès | La santé de la chaîne, en un seul chiffre |
| Latence au 95e centile | L’expérience du client le moins bien servi |
| Transactions en échec | Le volume à traiter, et sa tendance |
| Vues détaillées | Par banque, par rail, et par code d’erreur |
Les trois signaux, et ce qui les relie
Les métriques disent qu’il y a un problème, les traces disent où, les journaux disent pourquoi. Le passage de l’un à l’autre est ce que le bloc 5 fait construire.
Les trois certifications
Chaque palier atteste d’un périmètre différent.
| Certification | Ce qu’elle atteste |
|---|---|
| Practitioner | Collecte, exportateurs, langage d’interrogation, alertes |
| Payment Observability Engineer | Tableaux de bord, monétique, messagerie normalisée, bus, orchestration, objectifs de service |
| Payment Observability Architect | Traçage distribué, haute disponibilité, corrélation complète, vision multi-participants |
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | prometheus.io |
| Dépôt public | github.com/prometheus/prometheus |
À vérifier au moment de la qualification. Licence exacte, version courante, activité du projet, gestion des vulnérabilités et conditions de support évoluent. Le statut affiché sur ce radar ne vaut ni certification, ni aptitude au déploiement en production dans une infrastructure de paiement.
Les autres briques du domaine
Debezium · OpenSearch · Grafana · OpenTelemetry Collector · Fluent Bit