Observer c’est comprendre. Sans monitoring, vous découvrez les problèmes de production quand vos utilisateurs se plaignent — souvent trop tard. Prometheus et Grafana forment en 2026 le duo de référence pour l’observabilité des applications : Prometheus collecte et stocke les métriques, Grafana les visualise avec des dashboards et envoie des alertes. Cette stack est déployée par des milliers d’entreprises, des startups aux GAFAM, et son modèle pull-based le rend particulièrement adapté aux environnements containerisés. Ce guide vous permet de démarrer en moins d’une heure.
Architecture Prometheus : comprendre le modèle pull
Prometheus adopte un modèle pull : c’est lui qui va interroger régulièrement (scraping) les endpoints de métriques de vos applications, pas l’inverse. Chaque application expose ses métriques sur un endpoint HTTP `/metrics` au format texte Prometheus (format OpenMetrics). Prometheus récupère ces métriques toutes les N secondes selon votre configuration, les stocke dans sa base de données temporelle (TSDB) locale, et les rend interrogeables via PromQL.
Ce modèle a plusieurs avantages sur le push (StatsD, Graphite) : la découverte de cibles est centralisée dans la configuration Prometheus, chaque application n’a pas besoin de connaître l’adresse du serveur de métriques, et l’état de chaque cible (up/down) est directement visible dans Prometheus. L’inconvénient : les jobs de courte durée (scripts batch) disparaissent avant d’être scrapés — pour ces cas, utilisez le Pushgateway comme intermédiaire.
Les métriques Prometheus sont typées : Counter (valeur qui ne fait qu’augmenter, ex: nombre de requêtes), Gauge (valeur qui monte et descend, ex: utilisation CPU), Histogram (distribution de valeurs avec buckets, ex: latences de requêtes), et Summary (similaire à Histogram mais calculé côté client). Comprendre ces types est essentiel pour écrire des requêtes PromQL pertinentes et éviter les erreurs de calcul (rate() s’applique aux Counter, pas aux Gauge).
Installation avec Docker Compose : la voie rapide
La façon la plus simple de démarrer est Docker Compose. Créez un fichier `docker-compose.yml` avec trois services : Prometheus, Grafana et Node Exporter (qui expose les métriques système de la machine hôte). Voici la configuration de base :
« `yaml
version: ‘3.8’
services:
prometheus:
image: prom/prometheus:latest
volumes:
– ./prometheus.yml:/etc/prometheus/prometheus.yml
– prometheus_data:/prometheus
ports:
– ‘9090:9090’
command:
– ‘–config.file=/etc/prometheus/prometheus.yml’
– ‘–storage.tsdb.retention.time=30d’
grafana:
image: grafana/grafana:latest
volumes:
– grafana_data:/var/lib/grafana
ports:
– ‘3000:3000’
environment:
– GF_SECURITY_ADMIN_PASSWORD=motdepasse_securise
node-exporter:
image: prom/node-exporter:latest
ports:
– ‘9100:9100’
volumes:
prometheus_data:
grafana_data:
« `
Créez ensuite le fichier `prometheus.yml` de configuration :
« `yaml
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
– job_name: ‘prometheus’
static_configs:
– targets: [‘localhost:9090’]
– job_name: ‘node’
static_configs:
– targets: [‘node-exporter:9100’]
« `
Lancez avec `docker compose up -d`. Prometheus est accessible sur `:9090`, Grafana sur `:3000` (admin / motdepasse_securise). Vérifiez dans Prometheus > Status > Targets que vos deux cibles sont en état ‘UP’.
En production, exposez Prometheus et Grafana uniquement sur des interfaces internes (pas sur 0.0.0.0 publiquement). Utilisez un reverse proxy Nginx avec authentification basique ou OAuth2 (Grafana supporte nativement OAuth2 avec Google, GitHub, Okta). Configurez également TLS : Grafana accepte des certificats directement dans sa configuration, ou déléguez-le à Nginx/Traefik en frontal.
Instrumenter votre application Python avec le client Prometheus
Pour que Prometheus scrape votre application, celle-ci doit exposer un endpoint `/metrics`. Le client officiel Python est `prometheus_client`. Installez-le avec `pip install prometheus_client`. Voici un exemple avec Flask :
« `python
from flask import Flask
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
import time
app = Flask(__name__)
REQ_TOTAL = Counter(‘http_requests_total’, ‘Total HTTP requests’, [‘method’, ‘endpoint’, ‘status’])
REQ_LATENCY = Histogram(‘http_request_duration_seconds’, ‘HTTP request latency’, [‘endpoint’])
@app.before_request
def start_timer():
import flask; flask.g.start = time.time()
@app.after_request
def record_metrics(response):
latency = time.time() – flask.g.start
REQ_LATENCY.labels(endpoint=flask.request.path).observe(latency)
REQ_TOTAL.labels(method=flask.request.method, endpoint=flask.request.path, status=response.status_code).inc()
return response
@app.route(‘/metrics’)
def metrics():
return generate_latest(), 200, {‘Content-Type’: CONTENT_TYPE_LATEST}
« `
Les métriques les plus utiles à instrumenter pour une API web : nombre de requêtes par endpoint et code de statut (Counter), latence des requêtes par endpoint (Histogram avec buckets adaptés à votre SLA), nombre de connexions actives (Gauge), taux d’erreurs par type d’exception (Counter), et utilisation du pool de connexions à la base de données (Gauge). Ces cinq métriques suffisent à diagnostiquer 80 % des incidents de production.
Pour les applications Node.js, utilisez `prom-client`. Pour Java/Spring, Micrometer s’intègre nativement avec Prometheus via `micrometer-registry-prometheus`. Pour Go, le client officiel `prometheus/client_golang`. Dans tous les cas, le pattern est identique : définir les métriques au démarrage (singleton), les incrémenter/observer dans le code métier, exposer `/metrics`. L’écosystème Prometheus propose des exporters pour presque toutes les technologies : PostgreSQL, Redis, Nginx, Kafka, Elasticsearch.
PromQL : requêtes essentielles pour vos dashboards
PromQL est le langage de requête de Prometheus. Sa maîtrise est indispensable pour créer des dashboards pertinents. Voici les requêtes les plus utilisées. Taux de requêtes HTTP sur la dernière minute : `rate(http_requests_total[1m])`. Taux d’erreurs (codes 5xx) : `rate(http_requests_total{status=~’5..’}[5m]) / rate(http_requests_total[5m]) * 100`. Latence au 95e percentile : `histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))`.
Utilisation CPU par conteneur Docker : `rate(container_cpu_usage_seconds_total{name!= »}[5m]) * 100`. Mémoire utilisée par conteneur : `container_memory_usage_bytes{name!= »} / 1024 / 1024`. Ces métriques sont fournies par cAdvisor (intégré dans Docker Desktop, ou deployable séparément). Combinez-les avec vos métriques applicatives pour corréler la charge système avec la performance de votre code.
Les fonctions PromQL les plus importantes : `rate()` pour le taux de variation d’un Counter sur une fenêtre glissante, `irate()` pour un taux instantané (plus réactif mais bruité), `increase()` pour la somme des incréments sur une fenêtre, `by` et `without` pour agréger par labels, `topk(5, …)` pour les 5 valeurs les plus élevées. Évitez `irate()` dans les alertes — sa sensibilité aux pics transitoires génère trop de faux positifs.
Grafana : créer des dashboards efficaces
Grafana transforme les données Prometheus en visualisations compréhensibles. Commencez par ajouter Prometheus comme source de données : Configuration > Data Sources > Add > Prometheus, entrez l’URL `http://prometheus:9090` (ou l’IP de votre container). Testez la connexion avant de sauvegarder.
Importez des dashboards communautaires depuis grafana.com/grafana/dashboards au lieu de tout créer de zéro. Les dashboards les plus utiles : ID 1860 (Node Exporter Full — métriques système complètes), ID 13659 (Blackbox Exporter — monitoring des endpoints HTTP externes), ID 7362 (PostgreSQL), ID 763 (Redis). L’import se fait en quelques secondes : Dashboards > Import > saisir l’ID > Load.
Pour créer un dashboard personnalisé, utilisez les panels de type Time Series (courbes temporelles, idéal pour les taux et latences), Stat (valeur unique avec indicateur de tendance, idéal pour les uptime et compteurs globaux), Gauge (jauge circulaire, idéal pour les taux d’utilisation CPU/mémoire), et Table (tableau avec données brutes, idéal pour les listes d’erreurs). Organisez vos dashboards par équipe ou par service — évitez les dashboards ‘fourre-tout’ avec 40 panels qui noient l’information importante.
Alertmanager : configurer des alertes pertinentes
Alertmanager gère le routing des alertes définies dans Prometheus vers les canaux de notification (email, Slack, PagerDuty). Créez un fichier `alert.rules.yml` avec vos règles :
« `yaml
groups:
– name: application
rules:
– alert: HighErrorRate
expr: rate(http_requests_total{status=~’5..’}[5m]) / rate(http_requests_total[5m]) > 0.05
for: 2m
labels:
severity: warning
annotations:
summary: ‘Taux d erreur élevé sur {{ $labels.instance }}’
description: ‘Taux d erreur 5xx : {{ $value | humanizePercentage }}’
« `
Le paramètre `for` évite les faux positifs sur les pics transitoires : l’alerte n’est déclenchée que si la condition est vraie pendant plus de 2 minutes.
La philosophie des bonnes alertes : une alerte doit être actionnable, urgente et rare. Chaque alerte que reçoit l’équipe doit nécessiter une action humaine immédiate. Les alertes sur des métriques de symptômes (latence élevée, taux d’erreur) sont préférables aux alertes sur des causes (CPU élevé) — les causes sans impact utilisateur peuvent attendre le lendemain matin. Évitez le ‘alert fatigue’ : une équipe qui reçoit 50 alertes par jour en ignore la moitié.
En production, connectez Alertmanager à PagerDuty ou OpsGenie pour les alertes critiques (rotation d’astreinte, escalade automatique) et à Slack pour les alertes non urgentes. Configurez des plages de silence (silences) pour les maintenances planifiées — rien de pire qu’une tempête d’alertes lors d’un déploiement prévu. Grafana OnCall (disponible en free tier depuis 2023) offre une alternative open-source complète à PagerDuty.
Service Discovery : monitorer des infrastructures dynamiques
Dans les environnements containerisés (Kubernetes, Docker Swarm), les cibles changent dynamiquement : des pods démarrent et s’arrêtent en permanence, avec des IPs différentes à chaque fois. Le scraping statique (`static_configs`) ne suffit plus. Prometheus propose une vingtaine de mécanismes de service discovery pour s’adapter à ces environnements.
Sur Kubernetes, la configuration la plus courante utilise le service discovery natif de Prometheus :
« `yaml
scrape_configs:
– job_name: ‘kubernetes-pods’
kubernetes_sd_configs:
– role: pod
relabel_configs:
– source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: ‘true’
– source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
target_label: __address__
« `
Prometheus découvre automatiquement tous les pods annotés `prometheus.io/scrape: ‘true’` et scrape le port indiqué dans l’annotation `prometheus.io/port`. Ajoutez ces annotations dans vos manifests Kubernetes pour activer le monitoring d’un nouveau service en quelques secondes.
Pour Docker Compose sans Kubernetes, utilisez le service discovery Docker (file_sd_configs avec un fichier JSON que Docker met à jour) ou Consul pour les architectures microservices complexes. L’opérateur Prometheus pour Kubernetes (kube-prometheus-stack via Helm) installe Prometheus, Grafana, Alertmanager et une vingtaine de règles d’alerte pré-configurées pour Kubernetes en une seule commande — la solution recommandée pour les déploiements Kubernetes en production.
Rétention et coûts : Thanos et Grafana Mimir pour le long terme
Par défaut, Prometheus conserve 15 jours de métriques localement (configurable avec `–storage.tsdb.retention.time`). Pour une rétention longue durée (90 jours, 1 an) nécessaire pour les analyses de tendances et les audits, les options locales deviennent coûteuses en espace disque. C’est là qu’interviennent Thanos et Grafana Mimir, deux solutions open-source de stockage objet pour Prometheus.
Thanos s’intègre avec votre Prometheus existant via un sidecar container qui pousse les blocs de métriques vers un stockage objet (S3, GCS, Azure Blob). Un composant Query Federation permet d’interroger les métriques stockées depuis des années exactement comme des métriques récentes dans Prometheus. Le coût du stockage objet (S3 à 0,023 $/Go/mois) est négligeable comparé à un disque local dédié — pour 100 Go de métriques mensuelles, c’est 2,3 $/mois.
Pour les équipes SRE gérant de grandes infrastructures, Grafana Mimir (successeur de Cortex) propose une solution de monitoring multi-tenant, hautement disponible et scalable horizontalement. Il remplace complètement Prometheus local et offre une compatibilité totale avec PromQL et l’API Prometheus. Grafana Cloud propose Mimir en SaaS avec un free tier généreux (10 000 séries actives) — idéal pour démarrer sans infrastructure à gérer.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.