Quand la taverne monte en charge : Prometheus, Grafana et alerting avec Quarkus

La taverne tourne. Les clients sont servis. Les traces racontent déjà l'histoire de chaque commande.
Mais au fil de la soirée, une vérité s'impose :

voir ce qui s'est passé, c'est bien. Être prévenu avant que ça casse, c'est mieux.

Dans le premier chapitre, on a appris à observer la taverne depuis le comptoir : health, métriques, traces, logs corrélés.
Ici, on change de posture. On passe côté salle de contrôle.

L'objectif de ce second chapitre est simple :

• collecter ce que l'application raconte (Prometheus)
• lire les signaux rapidement (Grafana)
• réagir avant l'incident visible (Alertmanager)

Autrement dit : transformer /q/metrics en dispositif de pilotage.

Acte I — Quand la salle se remplit

Au début du service, tout paraît calme.
Puis les commandes s'enchaînent, les tournées s'accélèrent, et les questions changent :

• la taverne répond-elle encore ?
• le rythme de service tient-il ?
• la latence glisse-t-elle doucement vers le rouge ?

Dans le module observabilite-advanced-tutorial, on s'appuie sur trois signaux principaux :

• up{job="observabilite-advanced-tutorial"} pour la disponibilité
• tavern_advanced_order_count_total pour le volume de commandes
• tavern_advanced_order_seconds_* pour la latence

Ce trio suffit souvent à répondre à la question la plus importante en incident :

est-ce qu'on est en train de perdre la main ?

Acte II — La carte de la taverne

Avant d'ouvrir les dashboards, il faut savoir qui parle à qui.

La lecture est volontairement simple :

• Quarkus expose les métriques
• Prometheus les récolte
• Grafana les met en scène
• Alertmanager orchestre les alertes

Acte III — Le guetteur Prometheus

Prometheus, c'est le guetteur en haut de la tour.
Il ne boit pas, ne dort pas, et regarde la porte toutes les 15 secondes.

Il a deux missions :

• vérifier que la taverne répond (up)
• mesurer la cadence et la latence sans interruption

Quand il voit quelque chose d'anormal, il n'alerte pas à la première seconde.
Il attend un peu, pour éviter les fausses paniques.

C'est exactement le rôle des règles :

• TavernApiDown : l'API est indisponible depuis 30s

- alert: TavernApiDown
  expr: up{job="observabilite-advanced-tutorial"} == 0
  for: 30s
  labels:
    severity: critical
  annotations:
    summary: "La taverne ne repond plus"
    description: "Le scrape Prometheus vers l'API Quarkus echoue depuis 30s."

• TavernOrderLatencyP95High : la latence p95 dépasse 500ms pendant 1 minute

- alert: TavernOrderLatencyP95High
  expr: histogram_quantile(0.95, sum(rate(tavern_advanced_order_seconds_bucket[2m])) by (le)) > 0.5
  for: 1m
  labels:
    severity: warning
  annotations:
    summary: "Latence p95 des commandes trop elevee"
    description: "La latence p95 de tavern.advanced.order depasse 500 ms depuis 1 minute."

Ici, le p95 représente les clients qui attendent trop longtemps, même si la moyenne reste correcte.
C'est souvent ce signal qui révèle les soirées qui dérapent.

On peut les retrouver dans l'interface de Prometheus

Interlude — Dans les coulisses de Prometheus

Dans l'histoire, Prometheus ressemble à un guetteur.
Dans la technique, il fonctionne comme un métronome :

• il scrape à intervalle fixe
• il stocke des séries temporelles
• il exécute des règles d'alerte à cadence régulière

Concrètement, trois blocs sont essentiels dans sa configuration :

• scrape_configs : qui observer et où récupérer les métriques
• rule_files : quelles règles évaluer
• alerting : à qui envoyer les alertes déclenchées

Dans la taverne, le scrape principal cible :

• host.docker.internal:8080
• metrics_path: /q/metrics

Ce point mérite d'être explicite : la qualité de l'observabilité dépend d'abord de la qualité du scrape.
Si le scrape est mauvais, les dashboards et alertes le seront aussi.

Quelques requêtes PromQL utiles au comptoir

Quand un incident démarre, ces requêtes donnent une lecture rapide :

• Disponibilité :
  up{job="observabilite-advanced-tutorial"}
• Débit de commandes :
  sum(rate(tavern_advanced_order_count_total[1m]))
• Latence p95 :
  histogram_quantile(0.95, sum(rate(tavern_advanced_order_seconds_bucket[2m])) by (le))

Le plus important n'est pas de connaître cent requêtes.
C'est d'en maîtriser trois ou quatre qui répondent aux questions vitales.

Acte IV — Le tableau de bord du tavernier

Grafana joue un autre rôle : il transforme des lignes de métriques en décisions opérationnelles.

Le dashboard Tavern Advanced Overview est construit comme un tableau de salle :

• Order Throughput : est-ce que les commandes sortent encore ?
• Order Latency p95 : est-ce que ça ralentit pour les clients ?
• API Availability : est-ce que la taverne est ouverte ou fermée ?

Quand la pression monte, ce dashboard évite la chasse au trésor entre cinq outils.
En un coup d'oeil, on choisit la bonne investigation.

Interlude — L'art de lire Grafana sans se tromper

Un dashboard ne sert pas à faire joli.
Il sert à prendre la bonne décision au bon moment.

Dans une soirée tendue, on voit souvent trois erreurs de lecture :

• regarder une fenêtre de temps trop courte et conclure trop vite
• confondre un pic ponctuel avec une tendance
• analyser un panneau seul sans croiser disponibilité, débit et latence

Pour éviter ça, on suit cette méthode :

1. on commence avec une fenêtre last 15 minutes
2. on élargit à last 1 hour si le comportement semble instable
3. on croise toujours les trois panneaux avant de conclure

Exemple concret dans la taverne :

• Throughput monte
• Latence p95 monte aussi
• Disponibilité reste UP

Lecture probable : le service tient, mais il se dégrade sous charge.
Ce n'est pas une panne franche, c'est une perte de qualité de service.

Acte V — Le veilleur Alertmanager

Prometheus détecte le danger.
Alertmanager, lui, décide comment réveiller l'équipe.

Il regroupe, temporise et route les alertes pour éviter le bruit permanent.
Dans ce tutoriel, le receiver est minimal pour valider la chaîne.
En contexte réel, on branchera Slack, Teams, email ou PagerDuty.

L'idée n'est pas d'avoir plus d'alertes.
L'idée est d'avoir des alertes qu'on lit et qu'on traite.

Scénario terrain : Une soirée à la taverne

Plutôt qu'une simple checklist, voici un scénario narratif de validation, comme une garde en conditions réelles.

Scène 1 : Ouverture des portes

Le tavernier allume les lumières :

quarkus dev

Puis il lance les guetteurs :

docker-compose up -d

À ce stade, tout doit être prêt : API, collector, Jaeger, Prometheus, Grafana, Alertmanager.

Scène 2 — Le service nominal

Les premiers clients commandent des stouts. Le flux est régulier :

for i in {1..30}; do curl -s "http://localhost:8080/advanced-tavern/order?drink=stout" > /dev/null; done

Contrôle rapide au comptoir :

curl -s http://localhost:8080/q/metrics | grep tavern_advanced_order_count_total

Ce qu'on doit observer :

• le compteur tavern_advanced_order_count_total augmente
• le throughput monte dans Grafana
• la latence p95 reste basse (souvent autour de quelques dizaines de ms en local)

Ici, la salle est pleine, mais le service reste fluide.

Scène 3 — L'incident qui couve

Un client commande une boisson capricieuse : dragonfire.
Dans le module, ce cas simule un traitement plus lent.

for i in {1..40}; do curl -s "http://localhost:8080/advanced-tavern/order?drink=dragonfire" > /dev/null; done

Contrôle Prometheus (option utile) :

• ouvrir http://localhost:9090/graph
• exécuter :
  histogram_quantile(0.95, sum(rate(tavern_advanced_order_seconds_bucket[2m])) by (le))

La tension monte :

• le p95 grimpe (souvent > 1s)
• Prometheus passe l'alerte TavernOrderLatencyP95High en firing
• Alertmanager relaie l'événement

C'est exactement le moment où l'outillage évite le "on dirait que c'est lent".
On a un fait, horodaté, objectivable.

Scène 4 — Rideau baissé

On coupe l'API Quarkus (Ctrl+C) et on attend environ 45 à 60 secondes.

Ce qu'on doit voir :

• API Availability passe à DOWN dans Grafana
• TavernApiDown devient firing dans Prometheus
• l'alerte apparaît dans Alertmanager

Ensuite on redémarre Quarkus :

• les targets repassent en UP
• les alertes reviennent en resolved

La boucle de supervision est complète : détection, visualisation, alerte, retour à la normale.

Lecture rapide en astreinte

Quand il est 2h17 du matin et que la salle déborde, on garde cette séquence :

1. Disponibilité (up) : vivant ou non ?
2. Débit (count_total) : ça sert encore ou ça bloque ?
3. Latence p95 : les clients attendent-ils trop ?
4. Traces Jaeger : où part le temps ?

Ce rituel réduit le bruit, limite les hypothèses hâtives et accélère le diagnostic.

Pièges classiques de la taverne

Target Prometheus en DOWN

Souvent : API non démarrée, mauvais endpoint, ou accès réseau host/container mal réglé.

Alerte latence qui ne part jamais

Souvent : mauvaise métrique ciblée, fenêtre trop courte, ou trafic insuffisant pendant for.

Dashboard vide

Souvent : datasource non provisionnée, métriques pas encore produites, ou mauvais dossier de dashboard.

Dans les trois cas, une démarche séquentielle permet de revenir vite à un état lisible.

Ce que ce chapitre change vraiment

Avec ce complément, la taverne ne fait plus que raconter le passé.
Elle sait se surveiller en continu et prévenir avant la rupture.

On gagne :

• un tableau de bord lisible
• une détection précoce
• des alertes actionnables
• un meilleur temps de réaction

La différence est là :

on ne subit plus le pic de charge, on l'encadre.

Et après ?

Pour le prochain chapitre, les pistes naturelles sont :

• brancher Alertmanager à Slack/Teams
• formaliser des SLO (disponibilité, p95)
• ajouter des dashboards orientés produit
• relier chaque alerte à un runbook court

La taverne sera toujours pleine.
Mais l'équipe, elle, restera sereine.

Tout le code relatif à cet article peut être trouvé ici pour plus de détail :

GitHub - ErwanLT/quarkus-demo: Demo project for quarkus possibility

Demo project for quarkus possibility. Contribute to ErwanLT/quarkus-demo development by creating an account on GitHub.

GitHubErwanLT