Prometheus

Fiche express
Type	Système de monitoring et base de données de séries temporelles (métriques)
Éditeur	Projet CNCF (initialement SoundCloud)
Licence	Open source (Apache 2.0)
Modèle de collecte	Pull (scraping HTTP périodique)
Langage de requête	PromQL
Voir aussi	Grafana · Alertmanager · Graphite

Prometheus est un système open source de collecte et de stockage de métriques sous forme de séries temporelles (time series) : chaque valeur numérique est associée à un horodatage et à un ensemble de paires clé/valeur (labels) qui la qualifient. Né chez SoundCloud puis passé sous gouvernance CNCF, il s'est imposé comme la référence de fait pour le monitoring applicatif et infrastructure dans l'écosystème cloud-native, en particulier Kubernetes.

Modèle pull vs modèle push

Contrairement à des approches historiquement push, où c'est l'application qui envoie activement ses métriques vers un agrégateur (StatsD poussant vers Carbon dans l'écosystème Graphite, par exemple), Prometheus fonctionne selon un modèle pull : le serveur Prometheus interroge lui-même, à intervalle régulier (le scrape), un ensemble de cibles HTTP qui exposent leurs métriques sur un endpoint dédié (par défaut /metrics).

<mermaid> flowchart LR

   subgraph Cibles
     A[Application
expose /metrics]
     B[node_exporter
expose /metrics]
   end
   P[Serveur Prometheus] -->|scrape HTTP périodique| A
   P -->|scrape HTTP périodique| B
   P --> T[(TSDB locale)]
   P -->|alertes firing| AM[Alertmanager]
   G[Grafana] -->|requêtes PromQL| P

</mermaid>

Ce choix a plusieurs conséquences pratiques :

• la cible n'a pas besoin de connaître l'adresse du collecteur, c'est l'inverse — ce qui

 simplifie grandement la découverte de service (service discovery) à grande échelle,
 en particulier dans un environnement dynamique comme Kubernetes ;

• un scrape qui échoue (cible injoignable) est immédiatement visible comme telle (métrique

 up == 0), alors qu'en push l'absence de données peut aussi bien signifier
 « rien à signaler » que « l'agent est en panne » ;

• à l'inverse, le modèle pull suppose que le serveur Prometheus puisse joindre la cible en

 réseau, ce qui se prête moins bien à des workloads de très courte durée (jobs batch) —
 Prometheus prévoit pour ce cas un composant séparé, le Pushgateway, qui fait exception
 au modèle pull en acceptant que ces jobs y poussent leur résultat avant de terminer.

Format d'exposition des métriques

Une cible expose ses métriques en texte brut, un format simple et lisible devenu depuis un standard ouvert (OpenMetrics) :

# HELP http_requests_total Nombre total de requêtes HTTP traitées
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 27412
http_requests_total{method="GET",status="500"} 3

# HELP http_request_duration_seconds Distribution des temps de réponse
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 24054
http_request_duration_seconds_bucket{le="0.5"} 27380
http_request_duration_seconds_bucket{le="+Inf"} 27415
http_request_duration_seconds_sum 892.4
http_request_duration_seconds_count 27415

Types de métriques

• Counter — valeur qui ne fait qu'augmenter (ou repart à zéro lors d'un redémarrage),

 typiquement un nombre de requêtes ou d'erreurs cumulées.

• Gauge — valeur qui peut monter ou descendre librement (utilisation mémoire, nombre de

 connexions actives, taille d'une file).

• Histogram — répartit les observations dans des buckets cumulatifs (comme

 l'exemple ci-dessus) pour calculer ensuite des quantiles côté requête.

• Summary — proche de l'histogram mais calcule les quantiles côté client au moment de

 l'exposition plutôt qu'à la requête, avec des compromis différents en termes de coût
 d'agrégation entre plusieurs instances.

PromQL

PromQL (Prometheus Query Language) est le langage de requête utilisé pour interroger la base de séries temporelles, aussi bien pour le rendu de graphiques (dans Grafana par exemple) que pour la définition de règles d'alerte.

# Taux de requêtes par seconde sur les 5 dernières minutes
rate(http_requests_total[5m])

# Taux d'erreurs HTTP 5xx, agrégé toutes méthodes confondues
sum(rate(http_requests_total{status=~"5.."}[5m]))

# Latence médiane (quantile 0.5) à partir d'un histogram
histogram_quantile(0.5, rate(http_request_duration_seconds_bucket[5m]))

# Alerte simple : cible injoignable depuis plus d'une minute
up == 0

rate() calcule un taux par seconde à partir d'un counter en tenant compte des remises à zéro (redémarrage du process) ; c'est l'une des fonctions les plus utilisées de PromQL, un counter brut n'étant presque jamais exploitable tel quel.

Service discovery

Plutôt que de maintenir manuellement une liste statique de cibles à scraper, Prometheus intègre des mécanismes de découverte de service qui interrogent une source externe pour construire dynamiquement la liste des cibles :

• static_configs — liste fixe, pour un socle réduit ou des tests.
• file_sd — liste lue depuis un fichier JSON/YAML, régénéré par un script ou un outil

 tiers (CMDB, inventaire).

• kubernetes_sd — découverte native des pods, services et endpoints d'un cluster

 Kubernetes via son API, avec relabeling pour transformer les annotations/labels Kubernetes
 en labels Prometheus.

• consul_sd — découverte depuis le catalogue de services Consul.

Exemple de configuration de scrape avec découverte statique et Kubernetes :

scrape_configs:
  - job_name: 'node-exporters'
    static_configs:
      - targets: ['10.0.0.11:9100', '10.0.0.12:9100']

  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

Règles d'enregistrement et règles d'alerte

Prometheus évalue en continu deux types de règles, définies côté serveur :

• Recording rules — précalculent une expression PromQL coûteuse à intervalle régulier et

 en stockent le résultat comme nouvelle série, pour accélérer des tableaux de bord ou des
 requêtes fréquemment réutilisées.

• Alerting rules — évaluent une condition PromQL et font passer une alerte à l'état

 pending puis firing si la condition reste vraie au-delà d'une
 durée for donnée.

groups:
  - name: exemples
    rules:
      - record: job:http_errors:rate5m
        expr: sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))

      - alert: TauxErreurEleve
        expr: job:http_errors:rate5m > 5
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Taux d'erreurs HTTP élevé sur {{ $labels.job }}"

Prometheus ne fait quévaluer ces règles et transmettre les alertes firing : c'est Alertmanager, un composant séparé, qui prend ensuite en charge le regroupement, la déduplication et le routage effectif des notifications — voir cette page pour la suite du cycle de vie d'une alerte.

Stockage et rétention

Prometheus embarque son propre moteur de stockage local (TSDB), optimisé pour l'écriture et la lecture de séries temporelles sur une fenêtre de rétention typiquement courte à moyenne (quelques semaines). Ce n'est pas conçu, nativement, comme un entrepôt de données à très long terme ni pour une haute disponibilité multi-sites : les déploiements qui en ont besoin s'appuient sur le protocole remote_write pour répliquer les séries vers un backend de stockage long terme dédié (Thanos, Cortex, Mimir... à vérifier selon l'écosystème retenu), hors du périmètre de cette page.

Écosystème d'exporters

De nombreux systèmes n'exposent pas nativement de métriques au format Prometheus : un exporter est un petit programme intermédiaire qui traduit l'état d'un système tiers vers ce format. Les plus courants :

• node_exporter — métriques système d'une machine Linux (CPU, mémoire, disque, réseau).
• blackbox_exporter — sondes actives (HTTP, TCP, ICMP, DNS) pour vérifier la

 disponibilité d'un service depuis l'extérieur, à la manière d'un check Nagios/Centreon mais
 exposé au format Prometheus.

• des exporters existent pour la plupart des briques d'infrastructure courantes (bases de

 données, files de messages, reverse proxies...).

Voir aussi

• Grafana — frontal de visualisation le plus courant pour interroger Prometheus en PromQL
• Alertmanager — routage, regroupement et notification des alertes évaluées par Prometheus
• Graphite — approche antérieure, orientée push (StatsD/Carbon), utile pour situer le

 changement de modèle apporté par Prometheus