Prometheus : Collecte de métriques pour le cloud-native

Vous voulez surveiller vos applications et être alerté en cas de problème ? Prometheus collecte les métriques de vos services (CPU, mémoire, requêtes HTTP, erreurs…) et vous permet de créer des alertes quand quelque chose dysfonctionne.

En 5 minutes, vous aurez un PoC fonctionnel avec métriques collectées et première alerte. La production demande plus de travail (HA, sécurité, rétention) — ce guide vous donne les bases solides pour y arriver.

Quickstart : PoC en 5 minutes (Docker Compose)

Ce quickstart prouve la valeur de Prometheus immédiatement. Vous aurez :

• Prometheus qui collecte ses propres métriques + celles d’un node exporter
• Une requête PromQL fonctionnelle
• Une alerte qui se déclenche

1. Créer le fichier de configuration

   prometheus.yml

   global:
     scrape_interval: 15s
   
   scrape_configs:
     - job_name: 'prometheus'
       static_configs:
         - targets: ['localhost:9090']
   
     - job_name: 'node'
       static_configs:
         - targets: ['node-exporter:9100']
   
   rule_files:
     - 'alerts.yml'
   
   alerting:
     alertmanagers:
       - static_configs:
           - targets: ['alertmanager:9093']

2. Créer une règle d’alerte simple

   alerts.yml

   groups:
     - name: demo
       rules:
         - alert: TargetDown
           expr: up == 0
           for: 1m
           labels:
             severity: critical
           annotations:
             summary: "Target {{ $labels.instance }} is down"

3. Lancer la stack

   docker-compose.yml

   services:
     prometheus:
       image: prom/prometheus:v2.53.1
       ports:
         - "9090:9090"
       volumes:
         - ./prometheus.yml:/etc/prometheus/prometheus.yml
         - ./alerts.yml:/etc/prometheus/alerts.yml
       command:
         - '--config.file=/etc/prometheus/prometheus.yml'
         - '--web.enable-lifecycle'
   
     node-exporter:
       image: prom/node-exporter:v1.8.0
       ports:
         - "9100:9100"
   
     alertmanager:
       image: prom/alertmanager:v0.27.0
       ports:
         - "9093:9093"

   docker compose up -d

4. Vérifier que ça fonctionne

   • Prometheus : http://localhost:9090
   • Targets : http://localhost:9090/targets (2 targets UP)
   • Requête PromQL : tapez up dans Graph
   • Alertes : http://localhost:9090/alerts

Requête PromQL hello world

# Taux de requêtes HTTP par seconde (sur vos apps)
rate(prometheus_http_requests_total[5m])

Modèle mental : comment les briques s’emboîtent

Prometheus fonctionne en 5 étapes. Comprendre ce flux évite 80% des confusions :

Étape	Composant	Ce qu’il fait
1	Targets	Exposent /metrics au format Prometheus/OpenMetrics
2	Scraper	Pull HTTP toutes les 15s (configurable)
3	TSDB	Stocke les séries temporelles sur disque local
4	PromQL	Interroge les données (dashboards, API)
4b	Rules	Pré-calcule (recording) ou évalue les alertes
5	Alertmanager	Route et notifie (Slack, email, PagerDuty…)

Glissez pour voir

Prometheus ≠ Alertmanager

Ce sont deux composants séparés. Prometheus évalue les règles d’alerte et envoie les résultats à Alertmanager, qui gère le routage et les notifications.

Les 4 types de métriques

Type	Description	Quand l’utiliser
Counter	Compteur croissant uniquement	Requêtes, erreurs, bytes envoyés
Gauge	Valeur qui monte et descend	Mémoire, température, connexions actives
Histogram	Distribution avec buckets	Latences (recommandé), tailles de requêtes
Summary	Quantiles calculés côté client	Latences (moins agrégable que histogram)

Glissez pour voir

Histogram vs Summary

Préférez histogram côté serveur : les quantiles sont calculables côté PromQL et agrégables entre instances. Summary calcule côté client, ce qui bloque l’agrégation multi-pods.

Labels : puissance et piège n°1

Les labels sont des paires clé-valeur qui enrichissent vos métriques. C’est ce qui rend Prometheus si flexible :

# Sans labels : une seule série
http_requests_total

# Avec labels : filtrage et agrégation flexibles
http_requests_total{method="GET", status="200", handler="/api/users"}

Le piège : cardinalité explosive

Chaque combinaison unique de labels = une série temporelle en mémoire.

Label	Valeurs possibles	Impact
method	GET, POST, PUT, DELETE	4 séries → ✅ OK
status	200, 201, 400, 404, 500	5 séries → ✅ OK
user_id	1M utilisateurs	1M séries → ❌ OOM garanti
request_id	UUID unique	∞ séries → ❌ Catastrophe

Glissez pour voir

Anti-pattern cardinalité

Jamais de labels à valeurs unbounded (user_id, request_id, trace_id). Utilisez des histogrammes ou exportez vers un système de traces.

Prometheus ne collecte pas tout seul

Prometheus scrappe des endpoints /metrics. Pour exposer ces endpoints :

Outil	Rôle	Exemple
Exporter	Transforme une source → /metrics	node_exporter, mysql_exporter
Instrumentation	Code qui expose des métriques	Micrometer (Java), prometheus_client (Python)
OTel Collector	Routeur multi-signaux, peut exposer pour Prometheus	Alternative moderne

Glissez pour voir

Voir le guide Exporters pour les exporters courants.

Infos pratiques

Ports & endpoints

Port	Endpoint	Usage
9090	/	Interface web Prometheus
9090	/metrics	Métriques de Prometheus lui-même
9090	/targets	État des targets scrapées
9090	/alerts	Alertes actives
9090	/api/v1/query	API PromQL
9093	/	Interface Alertmanager

Glissez pour voir

Rétention

Par défaut : 15 jours sur disque local.

# Modifier la rétention
prometheus --storage.tsdb.retention.time=30d

Règle empirique : ~1-2 bytes par sample. 10 000 séries × 15s × 30 jours ≈ 50 Go.

Pour rétention > 30 jours ou multi-cluster → Mimir ou VictoriaMetrics (guides à venir).

Sécurité

Prometheus n’a pas d’authentification native. Ne jamais l’exposer sur Internet.

Bonnes pratiques :

• Mettre derrière un reverse proxy avec auth (nginx, Traefik, OAuth2 Proxy)
• Activer TLS (--web.config.file avec certificats)
• Limiter l’accès réseau (firewall, NetworkPolicy)

web-config.yml (TLS + auth basic)

tls_server_config:
  cert_file: /etc/prometheus/server.crt
  key_file: /etc/prometheus/server.key
basic_auth_users:
  admin: $2y$10$... # bcrypt hash

Parcours d’apprentissage

1. Installation Linux, Docker, Kubernetes (Helm)

2. Configuration prometheus.yml, scrape configs, rules

3. PromQL Maîtriser le langage de requête

4. Alertmanager Routage et notifications (séparé de Prometheus)

5. Exporters Node, MySQL, Blackbox, custom

6. Kubernetes kube-prometheus-stack, ServiceMonitor

Quand passer à l’échelle ?

Prometheus mono-instance a des limites. Voici les signaux d’alerte :

Symptôme	Solution
OOM fréquents, compactions lentes	Réduire cardinalité ou passer à VictoriaMetrics
Rétention > 30 jours requise	Mimir ou VictoriaMetrics + object storage
Multi-cluster sans vue globale	Mimir (multi-tenant) ou Thanos (fédération + query global)
Besoin de HA native	Mimir ou VictoriaMetrics cluster

Glissez pour voir

Thanos vs Mimir

Thanos est un compagnon de Prometheus pour HA + stockage long terme + query globale. Mimir est une réécriture “from scratch” plus moderne (Grafana Labs). Les deux sont valides selon votre écosystème.

Historique

Prometheus a été développé chez SoundCloud à partir de 2012 pour surveiller des architectures microservices dynamiques.

• 2012 : Création interne chez SoundCloud
• 2015 : Publication open source
• 2016 : Accepté par la CNCF (2ème projet après Kubernetes)
• 2018 : Statut “graduated” CNCF
• Aujourd’hui : Standard de facto pour l’observabilité cloud-native

À retenir

• Pull model : Prometheus scrappe les /metrics (pas de push)
• Labels : puissants mais attention à la cardinalité (pas de user_id)
• Alertmanager : composant séparé pour le routage et les notifications
• Rétention : 15 jours par défaut, disque local uniquement
• Sécurité : pas d’auth native, toujours mettre derrière un proxy
• Scaling : Mimir/VictoriaMetrics/Thanos pour multi-cluster ou long terme

Ressources officielles

• Documentation Prometheus
• GitHub Prometheus
• Awesome Prometheus

×

📖 Voir la documentation →