Prometheus monitoring : quickstart en 5 minutes et mise en production

Table des matières :

1. Prometheus monitoring en 2026 : l’anti-APM qui finit toujours par gagner
2. Architecture Prometheus : pull, TSDB et (surtout) la cardinalité
3. Quickstart Prometheus en 5 minutes : Docker Compose prêt à scraper
4. Du dashboard au pager : rules, Alertmanager et SLO (la partie qui fait mal)
5. Mise en production : sécurité, HA, rétention, et le monde réel (e-commerce inclus)

Prometheus monitoring en 2026 : l’anti-APM qui finit toujours par gagner

Prometheus monitoring, c’est un peu le retour du « bon sens » dans un monde où certains pensent qu’un agent magique va expliquer une panne sans qu’on ait à comprendre le système. Spoiler : non. Prometheus reste l’outil de référence quand vous voulez mesurer (vraiment), avec un modèle de données simple, un langage de requête puissant (PromQL) et une philosophie assumée : vous contrôlez vos métriques, au lieu d’implorer un SaaS opaque.

La définition officielle est d’ailleurs sans détour : « Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. » (Prometheus Docs, Overview : Prometheus Docs — Overview).

Le mot important ici, ce n’est pas “toolkit”, c’est “alerting”. Si votre stack “observabilité” se limite à des dashboards que personne ne regarde, vous faites du data décoratif.

Un point souvent sous-estimé en 2026 : Prometheus est devenu une brique standard (et durable) de l’écosystème cloud native. Le projet est “graduated” à la CNCF (Cloud Native Computing Foundation), ce qui est un bon signal de maturité, de gouvernance et d’écosystème (exporters, intégrations, opérateurs Kubernetes, etc.) : page projet CNCF. Ce n’est pas un argument “marketing” : ça réduit le risque de dépendre d’un outil qui disparaît, ou d’une API propriétaire qui change sans préavis.

Pour des équipes web/e-commerce, Prometheus monitoring coche aussi les cases opérationnelles : intégration rapide avec Nginx, HAProxy, MySQL, Redis, Postgres, Kubernetes, et tous les « exporters » du monde (ou presque). Et si vous êtes déjà dans une démarche plus large d’observabilité, l’articulation avec les traces et logs est désormais standard (exemplars, OpenTelemetry, etc.). Si le sujet vous intéresse côté unification, vous pouvez croiser avec l’article interne sur OpenTelemetry : unifier métriques, traces et logs pour l’observabilité.

Prometheus ne remplace pas toujours un APM — il remet surtout les priorités au bon endroit :

• Prometheus : idéal pour les signaux “système” et “service” (débit, latence, erreurs, saturation) et pour l’alerting fiable.
• APM/traces : idéal pour comprendre un parcours (ex. checkout) et isoler un hotspot précis dans le code.
• La combinaison (métriques + traces) : souvent la meilleure option, mais en commençant par des métriques utiles et peu coûteuses.

Enfin, Prometheus a un avantage “bêtement” pragmatique : vous pouvez l’installer sur un VPS, un cluster Kubernetes, une infra THD, ou même une machine dédiée — sans changer de modèle mental. Et dans un contexte européen (et souvent français) où l’on doit parfois arbitrer entre SaaS, résidence des données et contraintes de sécurité internes, garder l’option self-hosted est un vrai levier. Pour la partie infra et hygiène de base (durcissement, updates, supervision système), un détour par VPS Linux : guide de déploiement, durcissement et maintenance proactive fait rarement de mal… surtout quand on prétend faire de la prod.

Architecture Prometheus : pull, TSDB et (surtout) la cardinalité

Prometheus fonctionne principalement en pull : le serveur Prometheus interroge périodiquement des endpoints HTTP /metrics (format texte) exposés par vos services ou par des exporters. Cette approche simplifie la détection de “targets down” (si le scrape échoue) et évite la dépendance à un broker de métriques. En contrepartie, il faut gérer correctement la découvrabilité (static, filesd, consul, kubernetessd, etc.) et le réseau (NAT, segmentation, ACL). Oui, le monitoring devient un sujet d’architecture, pas une case à cocher.

Deux points concrets qui évitent des surprises dès les premiers déploiements :

• Le pull n’interdit pas le “push”, mais il l’encadre : pour des jobs batch (cron, CI, scripts), on utilise généralement un composant dédié (Pushgateway). Ça évite de transformer Prometheus en collecteur de logs déguisé.
• Le monitoring doit être “routable” : si vos workloads sont sur plusieurs VLANs, VPC ou environnements (prod / préprod), prévoyez explicitement comment Prometheus accède aux targets (bastion, peering, endpoints privés, règles pare-feu). Le nombre d’incidents “bêtes” vient d’un scrape cassé après un changement réseau.

Les données sont stockées dans une TSDB locale (Time Series Database) avec un modèle : metric name + labels = une série temporelle. Exemple : http_requests_total{service="checkout",code="500"}. C’est élégant, flexible… et dangereux si vous abusez des labels. Le piège classique : coller user_id, order_id, session ou url non normalisée en label. Résultat : explosion de la cardinalité, OOM, et soudain “Prometheus est nul”. Non : c’est votre modèle.

Une règle très opérationnelle : un label doit représenter une dimension avec un nombre fini et raisonnable de valeurs (service, instance, code HTTP, méthode, région), pas un identifiant. Voici une mini-table “anti-pattern” qui vaut cher en prod :

Label (mauvaise idée)	Pourquoi c’est toxique	Alternative utile
user_id, order_id	valeurs quasi uniques → cardinalité infinie	logs/traces, ou agrégats (ex. segment)
path="/checkout/1234"	URL non normalisée	normaliser : /checkout/:id (côté app)
error_message	chaînes arbitraires	classer en error_type, garder le message en logs
ip, email	cardinalité + risque données perso	métriques agrégées, anonymisation, logs contrôlés

Pour cadrer ce que vous devez mesurer, évitez le dashboard “CPU/RAM” qui donne l’illusion du contrôle. Appuyez-vous sur des méthodes reconnues. Google formalise les “four golden signals” : « The four golden signals are latency, traffic, errors, and saturation. » (Google SRE Book, Monitoring Distributed Systems : Google SRE Book — Monitoring Distributed Systems). Et côté infra, Brendan Gregg résume très bien l’approche USE : « For every resource, check utilization, saturation, and errors. » (Brendan Gregg, The USE Method : USE Method). Traduction : commencez par ce qui vous réveille la nuit, pas par ce qui est “joli”.

Enfin, un détail qui change la vie : monitorer Prometheus lui-même (sinon vous pilotez sans tableau de bord). Quelques métriques à garder sous les yeux dès le début :

• up (par job/instance) : “est-ce que je scrape vraiment ?”
• prometheus_tsdb_head_series : tendance cardinalité (ça doit rester sous contrôle)
• scrape_duration_seconds et scrape_samples_scraped : dérives, endpoints trop lourds
• prometheus_target_scrape_pool_scrapes_failed_total : erreurs de scrape (réseau, auth, timeouts)

Quickstart Prometheus en 5 minutes : Docker Compose prêt à scraper

Si vous avez Docker, vous pouvez faire un quickstart Prometheus monitoring en quelques minutes, sans ritualiser un “projet” observabilité de 6 mois. Objectif : Prometheus + node_exporter (métriques OS) + cAdvisor (métriques containers) + Grafana pour visualiser. Vous aurez déjà de quoi détecter saturation CPU, pression mémoire, I/O, et redémarrages… bref, la vraie vie.

Créez un docker-compose.yml minimaliste :

services:
  prometheus:
    image: prom/prometheus:v2.52.0
    container_name: prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus
      - --storage.tsdb.retention.time=15d
      - --web.enable-lifecycle
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  node_exporter:
    image: prom/node-exporter:v1.8.1
    container_name: node_exporter
    pid: host
    restart: unless-stopped
    ports:
      - "9100:9100"

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.49.1
    container_name: cadvisor
    privileged: true
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports:
      - "8080:8080"

  grafana:
    image: grafana/grafana:10.4.5
    container_name: grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=change-me-now
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"

volumes:
  prometheus_data:
  grafana_data:

Puis un prometheus.yml qui scrape les trois targets :

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["prometheus:9090"]

  - job_name: node
    static_configs:
      - targets: ["node_exporter:9100"]

  - job_name: cadvisor
    static_configs:
      - targets: ["cadvisor:8080"]

Lancez : docker compose up -d. Ouvrez http://localhost:9090 (Prometheus) et http://localhost:3000 (Grafana). Dans Grafana : ajoutez Prometheus comme datasource (http://prometheus:9090) puis importez un dashboard node_exporter (IDs officiels disponibles sur Grafana dashboards). Et là, miracle : vous voyez déjà des courbes. Oui, ce n’est pas encore une stratégie SLO, mais vous avez un socle mesurable.

Pour éviter le “ça marche chez moi” dès le quickstart, voici 5 vérifications rapides qui prennent 2 minutes et valident que le monitoring est réellement en place :

1) Dans Prometheus > Status > Targets, tout doit être UP.
2) Requête “sanity check” : up (vous devez voir 3 séries à 1).
3) CPU : rate(node_cpu_seconds_total[5m]) (les séries existent et évoluent).
4) Conteneurs : container_last_seen (cAdvisor remonte bien les containers).
5) Si Grafana ne montre rien : vérifiez l’URL datasource (dans Compose, http://prometheus:9090, pas localhost).

Deux améliorations “prod-friendly” même en local :

• Remplacez GF_SECURITY_ADMIN_PASSWORD=change-me-now par une variable dans un fichier .env (ou un secret) : c’est un réflexe à prendre.
• Ajoutez une limite de ressources (CPU/RAM) sur Grafana et cAdvisor si vous faites tourner ça sur un laptop ou un petit VPS, sinon vous allez “monitorer” un environnement biaisé par votre stack de monitoring.

Du dashboard au pager : rules, Alertmanager et SLO (la partie qui fait mal)

Le moment où Prometheus monitoring devient utile, c’est quand il déclenche des alertes actionnables. Pas des alertes “CPU > 80%” qui sonnent en continu et finissent “silencées” (la tombe opérationnelle). Les alertes doivent refléter un impact utilisateur (latence, erreurs) ou un risque imminent (disque à 95% avec croissance linéaire). Pour le web, vous pouvez compléter ce monitoring “infrastructure” par des signaux perçus côté client ; voir Real User Monitoring : RUM vs monitoring synthétique pour la performance web.

Techniquement, on met ça en place via des recording rules (pré-calculs) et des alerting rules (conditions). Exemple simplifié : calculer un taux d’erreur 5xx et alerter si > 1% sur 10 minutes.

rule_files:
  - /etc/prometheus/rules.yml

# rules.yml
groups:
  - name: http_sli
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

      - alert: High5xxErrorRate
        expr: (
          sum(rate(http_requests_total{code=~"5.."}[10m]))
          /
          sum(rate(http_requests_total[10m]))
        ) > 0.01
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "Taux d'erreurs 5xx > 1% (10m)"
          description: "Vérifier le service, la DB, ou un déploiement récent."

En e-commerce, le “taux d’erreur” seul n’est pas toujours suffisant : une dégradation de latence peut faire chuter la conversion sans augmenter les 5xx (timeouts client, abandons, latence de paiement). Si vous exposez un histogramme de durée (par exemple http_request_duration_seconds_bucket), une requête typique p95 ressemble à :

histogram_quantile(
  0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Et pour relier ça à un objectif, vous pouvez formaliser des SLO “simples” (sans tomber dans l’usine à gaz) :

SLI (ce que vous mesurez)	Exemple de SLO	Pourquoi c’est actionnable
Disponibilité HTTP	99,9% de requêtes non-5xx sur 30 jours	reflète l’expérience “ça marche”
Latence p95	p95 < 400 ms sur /checkout (hors assets)	protège la conversion
Saturation DB	pool < 85% utilisé en moyenne sur 5 min	évite la panne “progressive”
Background jobs	< 1% d’échecs sur 1h	évite les retards de traitement

Le piège courant : créer 50 alertes “symptômes” et aucune alerte “impact”. Une heuristique qui marche bien :

• Page (réveil) : impact utilisateur ou risque imminent.
• Ticket (heures ouvrées) : dérive, dette, capacité, hygiène (ex. cardinalité en hausse).

Ensuite, vous branchez Alertmanager (grouping, routing, silences, escalade vers Slack/Teams/PagerDuty). L’erreur classique : envoyer chaque alerte en DM au dev “qui a commit”. Le résultat est prévisible : plus personne ne répond. Faites du routing par service ownership, regroupez, imposez un for: (anti-flapping) et mettez des runbooks.

Exemple minimal (très simplifié) d’Alertmanager : regrouper, router par sévérité, et éviter le spam quand un composant amont tombe (inhibition). L’idée n’est pas de copier-coller “en prod”, mais de visualiser le mécanisme :

route:
  group_by: ["alertname", "job"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: "team-ops"
  routes:
    - matchers: ['severity="page"']
      receiver: "oncall"
    - matchers: ['severity="ticket"']
      receiver: "team-ops"

inhibit_rules:
  - source_matchers: ['alertname="TargetDown"']
    target_matchers: ['severity="page"']
    equal: ["job"]

receivers:
  - name: "oncall"
    # pagerduty_configs / webhook_configs / etc.
  - name: "team-ops"
    # slack_configs / email_configs / etc.

Dernier point essentiel : testez vos règles. Prometheus fournit promtool pour valider les configs et éviter la règle PromQL qui ne matche jamais (ou qui matche tout) :

• promtool check config prometheus.yml
• promtool check rules rules.yml

Si vous avez une démarche DevOps mature, alignez les alertes avec vos pratiques d’exploitation (post-mortems, playbooks, CI/CD) — et au passage, l’article les fondamentaux DevOps pour structurer vos pratiques pose des bases utiles.

Mise en production : sécurité, HA, rétention, et le monde réel (e-commerce inclus)

Passer en production, ce n’est pas “on ouvre le port 9090 et on prie”. Prometheus expose une UI, une API et souvent des métriques sensibles (top endpoints, noms de jobs, parfois des labels révélateurs). En pratique : segmentez réseau, placez Prometheus derrière un reverse-proxy avec authentification, appliquez du TLS, et limitez l’exposition. Pensez aussi aux endpoints /metrics : on y voit souvent des détails d’implémentation.

Deux réflexes “prod” concrets qui évitent des incidents bêtes :

• Ne mettez pas de données personnelles dans les labels (même “temporairement”). Une métrique vit longtemps (rétention, backups, remote storage), et finit souvent copiée dans plusieurs environnements.
• Séparez les surfaces : l’UI Prometheus/Grafana accessible aux équipes, mais les endpoints /metrics des services accessibles uniquement depuis le réseau de monitoring (ou via mTLS / policies Kubernetes).

Si votre culture sécurité est “on verra après”, allez lire Sécurité des API : authentification, autorisations et logique métier et branchez ça à votre pipeline via une logique DevSecOps (ex : DevSecOps-as-a-service : intégrer la sécurité au pipeline CI/CD).

Côté capacité, la variable qui tue est la cardinalité. Un ordre de grandeur : avec un scrape à 15s, une série produit ~5 760 échantillons/jour (86 400 / 15). Multipliez par 200 000 séries (ce qui arrive vite avec Kubernetes + labels mal gérés) et vous commencez à parler en milliards d’échantillons, donc en I/O, RAM et compaction TSDB. Ajoutez une rétention de 15 à 30 jours et vous obtenez un budget stockage qui n’est plus un détail.

Une méthode simple pour estimer “si vous êtes en train de craquer Prometheus” :

• Séries actives : suivez prometheus_tsdb_head_series (tendance = signal).
• Échantillons ingérés : regardez rate(prometheus_tsdb_head_samples_appended_total[5m]) (charge d’écriture).
• Durée de scrape : scrape_duration_seconds (si ça augmente, votre exposition /metrics devient coûteuse).
• Dérapage : scrape_samples_scraped qui double sans raison = souvent un label qui explose.

La bonne pratique : normaliser les labels, réduire la dimensionnalité, utiliser des recording rules pour les agrégats, et surveiller prometheus_tsdb_head_series et prometheus_tsdb_head_chunks. En Kubernetes, la discipline passe aussi par des relabel_configs (drop de labels inutiles, normalisation d’instances, suppression d’annotations bavardes) : c’est souvent le meilleur “ROI” technique après l’instrumentation.

Pour la haute dispo, Prometheus “pur” n’est pas un cluster : on duplique (deux Prometheus scrappent les mêmes targets) et on déduplique ensuite côté query (Thanos Querier) ou stockage (Cortex/Mimir, VictoriaMetrics). Si vous êtes sur Kubernetes, vous pouvez passer par le Prometheus Operator (ou kube-prometheus-stack) et externaliser la rétention via remote_write.

En France et plus largement en Europe, ce choix (stockage local vs remote) se combine souvent avec des exigences de résilience et parfois de localisation : garder la brique de métriques sur une infra maîtrisée, tout en envoyant une copie vers un stockage long terme. Si votre infra vise la très haute disponibilité, c’est exactement le genre de composant qui a sa place dans une offre comme Hébergement d’infrastructures THD (Très Haute Disponibilité) ou dans une démarche MCO/MCS structurée : MCO/MCS – Maintien en Conditions Opérationnelles / Maintien en Conditions de Sécurité.

Cas concret e-commerce (le genre qui arrive le vendredi à 18h, ou pendant les soldes) : le checkout commence à avoir une latence p95 qui grimpe, mais le CPU applicatif reste “raisonnable”. En exposant des métriques applicatives (http_server_duration_seconds histogram, db_pool_in_use, redis_commands_total), vous voyez souvent une saturation ailleurs : pool de connexions SQL, files d’attente, saturation disque sur la DB, ou throttling réseau. C’est là que PromQL est redoutable : corréler rate(errors) avec histogram_quantile(0.95, ...) et un signal de saturation.

Un mini-scénario très fréquent :

• la latence p95 augmente,
• les 5xx restent faibles,
• mais db_pool_in_use / db_pool_size frôle 1,0,
• et rate(http_requests_total[5m]) est stable.

Conclusion probable : le trafic n’explose pas, la capacité effective diminue (verrou DB, index, requête lente, vacuum, contention). Sans métriques applicatives, vous passez des heures à “regarder le CPU” au lieu de confirmer le goulot.

Checklist minimale (pas négociable) pour une mise en prod Prometheus monitoring propre : 1) un plan d’adressage + discovery (Kubernetes SD, Consul, file_sd),
2) des règles de relabeling pour maîtriser labels et targets,
3) une stratégie d’alerting (SLO/SLA, runbooks, escalade),
4) une rétention et un stockage adaptés (local + remote_write si besoin),
5) un durcissement sécurité (ACL, auth, TLS, secrets),
6) des tests et revues de config (lint PromQL, CI sur rules),
7) un monitoring de Prometheus/Alertmanager eux-mêmes (sinon l’alerte tombe en panne en silence).

Pour l’exécution “plateforme”, les équipes qui veulent industrialiser ça finissent souvent par demander un accompagnement : services DevOps pour créer et optimiser des infrastructures d’hébergement donne une idée du périmètre (discovery, HA, CI sur règles, runbooks, intégration sécurité, etc.).

Si vous ne deviez retenir qu’un truc : Prometheus n’est pas compliqué. Ce qui est compliqué, c’est d’accepter que monitorer, c’est choisir des métriques, des budgets d’erreur, des alertes, et une discipline d’exploitation. Le reste (Docker Compose, Helm chart, exporter) est littéralement la partie facile — donc évidemment, celle qu’on fait en premier.