Prometheus : monitoring et types de métriques

Vous voulez surveiller vos applications et être alerté en cas de problème ? Prometheus est le système de monitoring open source de référence, projet CNCF au même titre que Kubernetes. Son principe : il scrape (interroge en HTTP) les endpoints /metrics de vos services et stocke ces métriques comme des séries temporelles, que vous interrogez ensuite en PromQL et qui déclenchent vos alertes.

Ce modèle pull (Prometheus va chercher les données, au lieu de les recevoir) et les quatre types de métriques (counter, gauge, histogram, summary) sont le cœur du sujet. 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.

Ce que vous allez apprendre

• Lancer un PoC Prometheus en 5 minutes avec Docker Compose
• Comprendre le modèle pull et les 4 types de métriques (counter, gauge, histogram, summary)
• Écrire vos premières requêtes PromQL et maîtriser les labels (et leur piège de cardinalité)
• Brancher Alertmanager pour les alertes et Grafana pour la visualisation
• Savoir quand passer à l'échelle (Thanos, Mimir, VictoriaMetrics)

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']

   Beaucoup d'applications exposent nativement un endpoint Prometheus, sans exporter dédié. C'est le cas de Traefik : voir observer Traefik avec Prometheus.

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

   compose.yaml

   services:
     prometheus:
       image: prom/prometheus:v3.13.0@sha256:c6b27ea434f8389bfe233fbc7be381cf50587c286e871bc842008f5a1b1908a7  # Prometheus 3.13 (LTS : v3.5.x)
       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.11.1@sha256:e9cff4fc67b1818f8c97adb115b9f12c9a54b533de86765d4a0effc01b357205  # node_exporter 1.11.1
       ports:
         - "9100:9100"
   
     alertmanager:
       image: prom/alertmanager:v0.33.1@sha256:9e082985f56f4c8c9f724e18f2288c6708f472e56a5286b8863d080434ea065d  # Alertmanager 0.33.1
       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 types de métriques Prometheus (counter, gauge, histogram, summary)

Une métrique Prometheus est une valeur numérique nommée, mesurée dans le temps. Prometheus en distingue quatre types, et choisir le bon dès l'instrumentation évite de tout refaire ensuite. C'est le socle à connaître avant d'écrire la moindre requête PromQL.

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

Prochaines étapes

Une fois les métriques collectées, le parcours naturel mène de l'installation à la visualisation. Grafana est la brique qui transforme ces métriques en dashboards lisibles.

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

7. Visualiser avec Grafana Brancher Prometheus comme datasource et bâtir vos dashboards

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
• Prometheus 3 (dernière stable 3.13, LTS 3.5.x) : OTLP natif (ingestion OpenTelemetry), UTF-8 dans les noms de métriques, Remote Write 2.0, nouvelle interface web

Ressources officielles

• Documentation Prometheus
• GitHub Prometheus
• Awesome Prometheus

×

📖 Voir la documentation →