Projet · Phase 8.2

Supervision (2/5) — Prometheus & les métriques

Le pilier fondateur. On déploie Prometheus sur le cluster et on découvre son modèle : il va lui-même chercher les métriques (pull), les stocke en séries temporelles, et les interroge avec PromQL.

⏱ ~2 hNiveau avancéPrérequis : Supervision (1/5)Pratique · TP
L’idée reçue

« Les applications envoient leurs métriques au système de supervision. »

Avec Prometheus, c’est l’inverse : c’est lui qui va chercher les métriques, en interrogeant régulièrement chaque cible. Ce modèle pull (par opposition au push) change tout : la découverte des cibles, la fiabilité, la simplicité. Comprendre ce renversement, c’est comprendre Prometheus.

À la fin de ce module, tu sauras…

  • Déployer Prometheus sur le cluster K3s (via Helm)
  • Expliquer le modèle pull et le scraping
  • Comprendre ce qu’est une série temporelle et une métrique
  • Interroger tes données avec PromQL

01Déployer Prometheus

Expérience 1

Réutilise Helm (Phase 5)

On installe la stack via le chart communautaire de référence, dans un namespace dédié. Tu retrouves Helm, vu en Phase 5 :

Manipule
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace observabilite
helm install prometheus prometheus-community/prometheus -n observabilite
Manipule
kubectl -n observabilite get pods
Observe
prometheus-server-xxxx                 1/1  Running
prometheus-node-exporter-xxxx          1/1  Running
prometheus-kube-state-metrics-xxxx     1/1  Running
Plusieurs composants sont apparus : le serveur Prometheus, mais aussi des exporters. Chacun a un rôle dans la collecte.
Comprends serveur & exporters

Le serveur Prometheus collecte et stocke. Les exporters exposent des métriques dans un format que Prometheus comprend : node-exporter publie les métriques des nodes (CPU, RAM, disque), kube-state-metrics celles de l’état Kubernetes (Pods, Deployments…). Un exporter est un traducteur : il rend une source (l’OS, l’API K8s…) « lisible » par Prometheus. Pour instrumenter ta propre app, tu ajouteras un exporter ou un endpoint /metrics.

02Le modèle pull : Prometheus vient chercher

Expérience 2

Voir les cibles que Prometheus interroge

Accède à l’interface de Prometheus (port-forward, comme en Phase 5) :

Manipule
kubectl -n observabilite port-forward svc/prometheus-server 9090:80

Ouvre http://localhost:9090, puis Status → Targets.

Observe
Une liste de cibles (targets), chacune avec un état UP et une URL /metrics. Prometheus interroge chacune à intervalle régulier (le scrape) et récupère ses chiffres.
Comprends pull vs push, et pourquoi ce choix

En modèle pull, Prometheus détient la liste des cibles et va tirer (scrape) leurs métriques via HTTP GET /metrics, toutes les X secondes. Avantages : Prometheus sait immédiatement si une cible ne répond plus (elle passe DOWN = signal en soi), la config est centralisée, et les cibles n’ont rien à connaître du serveur. Dans un cluster, Prometheus découvre même les cibles automatiquement (service discovery Kubernetes) — les Pods qui apparaissent sont scrappés sans config manuelle. Le modèle push existe (d’autres outils l’utilisent), mais le pull s’accorde parfaitement au dynamisme de Kubernetes.

03Métrique & série temporelle

Expérience 3

Ta première requête

Dans l’onglet Graph, tape une métrique et exécute :

Manipule
node_memory_MemAvailable_bytes
Observe
Un graphe apparaît : la mémoire disponible, dans le temps. Chaque point = une mesure horodatée. C’est une série temporelle : le format natif de toute métrique.
Comprends anatomie d’une métrique

Une métrique Prometheus = un nom (node_memory_MemAvailable_bytes) + des labels (paires clé-valeur : instance=“worker-1”) + une valeur horodatée. Les labels permettent de filtrer et regrouper (« la mémoire, mais seulement sur worker-1 »). Une série temporelle est la suite des valeurs d’une métrique+labels au fil du temps. Ce modèle — nom + labels + valeurs dans le temps — est le fondement ; tout le reste (requêtes, graphes, alertes) s’appuie dessus.

04Interroger avec PromQL

Expérience 4

Transformer les données brutes en information

PromQL est le langage de requête de Prometheus. Essaie ces exemples, du simple au calculé :

Manipule
up
rate(container_cpu_usage_seconds_total[5m])
sum(kube_pod_status_phase{phase="Running"})
Observe
up montre l’état (1/0) de chaque cible ; rate(…[5m]) calcule l’évolution du CPU sur 5 minutes ; sum(…) agrège le nombre de Pods en cours. De la donnée brute, tu tires une réponse.
Comprends la logique de PromQL

PromQL manipule des séries temporelles : tu sélectionnes (par nom + labels), tu appliques des fonctions (rate pour un taux de variation, avg/sum/max pour agréger), et tu filtres. rate(…[5m]) est central : il calcule la vitesse d’évolution d’un compteur sur une fenêtre — c’est ainsi qu’on transforme « nombre total de requêtes » en « requêtes par seconde ». Ces mêmes requêtes alimenteront les tableaux de bord (module suivant) et les alertes (module 8.5). Apprendre à poser la question est le vrai savoir-faire.

Ce que tu retiens

Prometheus collecte les métriques en modèle pull : il scrape les cibles (serveur + exporters) via /metrics, et découvre même les Pods automatiquement dans le cluster. Il stocke tout en séries temporelles (nom + labels + valeurs horodatées), qu’on interroge avec PromQL. C’est le socle : dashboards et alertes s’appuieront sur ces requêtes.

Mini-projet

Explore les métriques de ton infra

À faire

  1. Déploie Prometheus sur le cluster via Helm, dans un namespace dédié.
  2. Ouvre l’interface et explore Status → Targets : identifie tes cibles UP.
  3. Interroge 3 métriques : mémoire d’un node, CPU d’un Pod, nombre de Pods Running.
  4. Écris une requête PromQL avec rate(…[5m]) et une avec sum(…).
  5. Provoque un changement (scale un Deployment) et observe la métrique bouger.
  6. Documente dans BookStack : modèle pull, exporter, série temporelle, une requête PromQL utile.
Fil rouge — Tu as les chiffres, mais les lire dans l’interface brute de Prometheus est austère. Au module suivant, on branche Grafana pour transformer ces requêtes en tableaux de bord clairs et vivants.

?Auto-évaluation

1. Qu’est-ce que le modèle pull de Prometheus ?

Prometheus va lui-même chercher (scrape) les métriques sur les cibles via HTTP, à intervalle régulier, au lieu que les cibles les lui envoient. Une cible qui ne répond plus passe DOWN — un signal en soi.

2. À quoi sert un exporter ?

À exposer les métriques d’une source (OS, API Kubernetes, application) dans un format que Prometheus sait scraper. C’est un traducteur vers le format Prometheus.

3. Qu’est-ce qu’une série temporelle ?

La suite des valeurs horodatées d’une métrique identifiée par un nom et des labels. C’est le format natif de toutes les données de Prometheus.

Connecte-toi pour enregistrer ta progression.

Suite → Supervision (3/5) — Grafana & les tableaux de bord