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

Créer le fichier de configuration

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.

Créer une règle d'alerte simple

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

Lancer la stack

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

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

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

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

Modèle mental Prometheus : Targets → Scrape → TSDB → PromQL/Rules → Alertmanager

É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…)

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)

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

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

Voir le guide Exporters pour les exporters courants.

Infos pratiques

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

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).

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)

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

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

FAQ : questions fréquentes

Les questions les plus posées sur Prometheus, avec une réponse directe à chacune : différence avec Grafana, gratuité, types de métriques, installation et passage à l'échelle.

Qu'est-ce que Prometheus ?

Prometheus est un système de monitoring open source et projet CNCF qui collecte des métriques en interrogeant (scrape) les endpoints /metrics de vos services, les stocke en séries temporelles, puis les interroge en PromQL et déclenche des alertes via Alertmanager.

Le standard du monitoring cloud-native

Prometheus est un système de monitoring open source, projet CNCF au statut graduated comme Kubernetes. Son principe repose sur le modèle pull : Prometheus scrape (interroge en HTTP) les endpoints /metrics de vos services à intervalle régulier.

Il stocke ces métriques comme des séries temporelles dans une base locale (TSDB).
Vous les interrogez avec le langage PromQL.
Les règles d'alerte partent vers Alertmanager, un composant séparé qui gère le routage et les notifications.

docker run -p 9090:9090 prom/prometheus
# Interface web : http://localhost:9090

Projet créé chez SoundCloud en 2012, open source depuis 2015, il est aujourd'hui le standard de facto de l'observabilité des métriques.

Prometheus ou Grafana : quelle différence ?

Prometheus collecte, stocke et interroge les métriques ; il n'est pas conçu pour les tableaux de bord. Grafana ne stocke rien : il se branche sur Prometheus comme source de données et affiche les dashboards. Les deux sont complémentaires : Prometheus pour la donnée, Grafana pour la visualisation.

Complémentaires, pas concurrents

La confusion est fréquente : Prometheus et Grafana ne font pas le même travail et s'utilisent ensemble.

Rôle	Prometheus	Grafana
Collecte des métriques	Oui (scrape)	Non
Stockage (séries temporelles)	Oui (TSDB)	Non
Requêtes	PromQL	Via la source de données
Tableaux de bord	Basique	Riche, sa spécialité

Prometheus fournit la donnée ; Grafana se branche dessus comme source de données et construit des dashboards lisibles. On garde Prometheus pour le stockage et les alertes, et Grafana pour la visualisation. Voir Grafana.

Prometheus est-il gratuit ?

Oui, Prometheus est entièrement gratuit et open source sous licence Apache 2.0, sans édition payante. C'est un projet CNCF au statut graduated, comme Kubernetes. Le seul coût est l'infrastructure qui l'héberge : stockage disque pour les séries temporelles et ressources de calcul.

Quels sont les 4 types de métriques Prometheus ?

Prometheus distingue quatre types de métriques : counter (compteur qui ne fait qu'augmenter, ex. requêtes), gauge (valeur qui monte et descend, ex. mémoire), histogram (distribution en buckets, recommandé pour les latences) et summary (quantiles calculés côté client).

Counter, gauge, histogram, summary

Choisir le bon type de métrique dès l'instrumentation évite de tout refaire ensuite.

Type	Comportement	Quand l'utiliser
Counter	Croît uniquement	Requêtes, erreurs, octets envoyés
Gauge	Monte et descend	Mémoire, température, connexions actives
Histogram	Distribution en buckets	Latences (recommandé), tailles
Summary	Quantiles côté client	Latences, moins agrégable

Pour les latences, préférez histogram : les quantiles se calculent en PromQL et s'agrègent entre instances, ce que summary ne permet pas puisqu'il calcule côté client.

Comment installer Prometheus rapidement ?

Le plus rapide est Docker Compose : un service prom/prometheus exposé sur le port 9090, avec un fichier prometheus.yml monté qui définit les scrape_configs. Lancez avec docker compose up -d, puis ouvrez http://localhost:9090/targets pour vérifier que les cibles sont UP.

Un PoC en 5 minutes avec Docker Compose

Le chemin le plus court passe par Docker Compose. Vous montez un fichier prometheus.yml qui définit les scrape_configs, puis vous lancez le conteneur prom/prometheus sur le port 9090.

services:
  prometheus:
    image: prom/prometheus:v3.13.0
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

docker compose up -d

Vérifiez ensuite sur http://localhost:9090/targets que les cibles sont UP, puis tapez up dans l'onglet Graph. Le détail (règles d'alerte, node_exporter) est dans le guide d'installation.

Qu'est-ce que PromQL ?

PromQL (Prometheus Query Language) est le langage qui interroge les séries temporelles de Prometheus. Il filtre par labels, comme http_requests_total{status="500"}, et applique des fonctions comme rate() pour un taux par seconde. Il alimente les dashboards, l'API et les règles d'alerte.

Le langage de requête de Prometheus

PromQL (Prometheus Query Language) interroge les séries temporelles stockées par Prometheus. C'est lui qui alimente les dashboards, l'API et les règles d'alerte.Deux mécanismes de base :

Filtrer par labels entre accolades ;
Appliquer une fonction, par exemple rate() pour un taux par seconde sur une plage de temps.

# Taux de requêtes HTTP en erreur 500, par seconde, sur 5 minutes
rate(http_requests_total{status="500"}[5m])

Le guide dédié PromQL détaille les sélecteurs, les fonctions et l'agrégation.

Quand passer de Prometheus à VictoriaMetrics, Thanos ou Mimir ?

Prometheus mono-instance suffit tant qu'il tient en mémoire et que 15 à 30 jours de rétention locale conviennent. Passez à VictoriaMetrics ou Mimir pour la rétention longue et la haute disponibilité, à Thanos ou Mimir pour une vue multi-cluster. Le premier signal d'alerte est l'OOM récurrent.

Les signaux qui imposent le passage à l'échelle

Une instance Prometheus unique suffit longtemps : tant qu'elle tient en mémoire et que 15 à 30 jours de rétention locale conviennent, inutile de complexifier.

Symptôme	Solution
OOM fréquents, compactions lentes	Réduire la cardinalité ou VictoriaMetrics
Rétention > 30 jours requise	Mimir ou VictoriaMetrics + object storage
Multi-cluster sans vue globale	Thanos (fédération) ou Mimir (multi-tenant)
Haute disponibilité native	Mimir ou VictoriaMetrics en cluster

Le premier signal d'alerte concret est l'OOM récurrent : la mémoire est le facteur limitant de Prometheus, souvent à cause d'une cardinalité de labels trop élevée.