Module 1 — Prometheus et Grafana : métriques réellement collectées

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 9 minutes

---

Le problème de l’observabilité

Le Module 1 du cours Linux & Shell a montré un script de supervision qui interroge l’état d’un serveur à un instant donné. Ça devient insuffisant dès qu’il faut : garder un historique (que s’est-il passé il y a 3 heures ?), corréler plusieurs métriques entre elles, ou déclencher une alerte automatique. C’est le rôle d’une pile d’observabilité — ici, Prometheus (collecte et stockage des métriques) et Grafana (visualisation).

Instrumenter une application

app.py (extrait)

from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST

REQUEST_COUNT = Counter("app_requests_total", "Nombre total de requêtes", ["endpoint"])
REQUEST_LATENCY = Histogram("app_request_latency_seconds", "Latence des requêtes", ["endpoint"])

@app.route("/")
def index():
    with REQUEST_LATENCY.labels(endpoint="/").time():
        REQUEST_COUNT.labels(endpoint="/").inc()
        ...
        return {"message": "ok"}

@app.route("/metrics")
def metrics():
    return Response(generate_latest(), mimetype=CONTENT_TYPE_LATEST)

La bibliothèque prometheus-client gère elle-même l’agrégation et l’exposition au format texte que Prometheus attend — l’application n’a qu’à incrémenter un Counter ou mesurer une durée avec un Histogram. Vérification directe, après quelques requêtes réelles :

$ curl -s http://localhost:5002/metrics | grep app_requests_total
app_requests_total{endpoint="/"} 30.0

Configurer Prometheus pour scraper cette application

prometheus.yml

global:
  scrape_interval: 5s

scrape_configs:
  - job_name: "app"
    static_configs:
      - targets: ["app:5000"]

Prometheus fonctionne en pull (il vient lui-même interroger /metrics toutes les 5 secondes), contrairement à beaucoup de systèmes de logs qui fonctionnent en push (l’application envoie activement ses données) — un choix de conception qui simplifie la découverte de service : Prometheus a juste besoin de connaître l’adresse de la cible, pas l’inverse.

Vérifié réellement :

$ curl -s http://localhost:9090/api/v1/targets
app         up    http://app:5000/metrics
prometheus  up    http://localhost:9090/metrics

Les deux cibles sont up : Prometheus a bien établi la connexion et collecte les métriques.

Interroger les métriques avec PromQL

$ curl -s 'http://localhost:9090/api/v1/query?query=app_requests_total'
{
  "status": "success",
  "data": {
    "result": [{
      "metric": {"endpoint": "/", "instance": "app:5000", "job": "app"},
      "value": [1789252355.442, "30"]
    }]
  }
}

Une requête un peu plus utile en production — le taux de requêtes par seconde sur la dernière minute, plutôt que le total brut depuis le démarrage :

rate(app_requests_total[1m])

Grafana : visualiser ces métriques dans le temps

Après avoir déclaré Prometheus comme source de données (via l’API Grafana) et créé un tableau de bord avec deux panneaux, capture réelle du tableau de bord après avoir généré du trafic :

• Panneau « Requêtes totales » : affiche 80, correspondant exactement au nombre de requêtes réellement envoyées à l’application pendant cette démonstration.
• Panneau « Latence (p50) » : un graphique temporel affichant une latence oscillant autour de 0,075 seconde — cohérent avec le code de l’application, qui simule volontairement un traitement de 10 à 150 millisecondes (time.sleep(random.uniform(0.01, 0.15))) à chaque requête.

Ce ne sont pas des chiffres d’exemple recopiés d’un tutoriel : ce sont les valeurs réellement retournées par la pile Prometheus + Grafana de ce cours, après un trafic réellement généré.

Alerting : la suite logique

Une fois les métriques collectées, l’étape suivante consiste à définir des règles d’alerte — par exemple, alerter si rate(app_requests_total{endpoint="/api/paiement"}[5m]) chute brutalement (symptôme possible d’une panne en amont), ou si la latence p99 dépasse un seuil pendant plus de 5 minutes. Prometheus sépare cette responsabilité dans un composant dédié, l’Alertmanager, qui reçoit les alertes déclenchées et les route (Slack, e-mail, PagerDuty) selon des règles de regroupement et de déduplication — au-delà du périmètre pratique de ce cours, mais la brique naturelle suivante une fois les métriques en place.

Prochaine étape

Module 2 : ELK Stack — centraliser et rechercher des journaux