📈 Prometheus – Monitoring, Métriques & Alerting

Les 4 Composants

• 1. Prometheus Server : Le cœur. C'est lui qui fait le "Scraping" (collecte), qui stocke dans sa **TSDB** (Time Series Database), et qui exécute les requêtes **PromQL**.
• 2. Cibles (Targets) / Exporters : Les applications (ex: votre API) ou les "Exporters" (ex: node_exporter pour les serveurs) qui exposent le endpoint /metrics.
• 3. Alertmanager : Un service (souvent séparé) qui reçoit les "alertes" de Prometheus, les dé-duplique, les groupe, et les route (Email, Slack, PagerDuty).
• 4. Clients (UI) : L'UI web de Prometheus (pour PromQL) ou (le plus souvent) Grafana.

Schéma de flux

[Image d'une architecture Prometheus]
+------------------------------------------------------+
| SERVEUR PROMETHEUS                                   |
| +----------------+  +-----------------------------+  |
| | Service        |  | TSDB                        |  |
| | Discovery      |  | (Stockage local)            |  |
| +----------------+  +-----------------------------+  |
|         |           | (PromQL)                     |
|         ▼           ▲                              |
| +----------------+  |                              |
| | Scraping Engine|--+                              |
| +----------------+                                 |
|         | (Pull /metrics)                          |
|         |                                          |
|         +-----------------------+                  |
|         |                       |                  |
|         ▼                       ▼                  |
| +--------------+      +------------------+         |
| | Cible 1      |      | Cible 2 (Node)   |         |
| | (App /metrics) |      | (node_exporter)  |         |
| +--------------+      +------------------+         |
|                                                    |
| (Alertes) ▼                                        |
| +--------------+      (Requêtes) ^                 |
| | Alertmanager |                 |                 |
| +--------------+                 |                 |
|    |                             |                 |
|    ▼ (Email/Slack)     +------------------+        |
|                        | Grafana (UI)     |        |
|                        +------------------+        |
+------------------------------------------------------+

docker run (Simple)

Nécessite un fichier prometheus.yml local.

# (Créer /home/user/prometheus.yml d'abord)

docker run -d \
    --name prometheus \
    -p 9090:9090 \
    -v /home/user/prometheus.yml:/etc/prometheus/prometheus.yml \
    -v prom-data:/prometheus \
    prom/prometheus:latest

# -v (config)
# -v (persistance)

docker-compose.yml (Stack Prometheus + Grafana)

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prom-data:/prometheus
    # (Permet à Grafana de se connecter via http://prometheus:9090)

  grafana:
    image: grafana/grafana-oss:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana

volumes:
  prom-data:
  grafana-data:

La Time Series (Série Temporelle)

Une "time series" est un flux de timestamps (temps) et de valeurs (nombres).

Dans Prometheus, chaque time series est identifiée **uniquement** par son **Nom de Métrique** ET son **jeu de Labels** (clés-valeurs).

Syntaxe

METRIC_NAME{LABEL1="value1", LABEL2="value2"}  VALEUR

Exemple (/metrics)

# HELP http_requests_total Total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="GET", path="/api/users"} 50
http_requests_total{method="POST", path="/api/users"} 10
http_requests_total{method="GET", path="/api/status"} 102

# HELP node_cpu_usage_percentage CPU usage.
# TYPE node_cpu_usage_percentage gauge
node_cpu_usage_percentage{instance="server1", core="0"} 80.5
node_cpu_usage_percentage{instance="server1", core="1"} 10.0

Labels (La puissance)

Les labels sont la clé de PromQL. Ils permettent l'agrégation "multi-dimensionnelle".

Ne *jamais* mettre de valeurs variables (ex: ID utilisateur) dans un nom de métrique. Mettez-les en labels.

Mauvais (Explosion de cardinalité)

http_requests_GET_api_users 50
http_requests_POST_api_users 10

Bon (Labels)

http_requests_total{method="GET", path="/api/users"} 50
http_requests_total{method="POST", path="/api/users"} 10

Prometheus ajoute aussi des labels (job, instance) lors du scrape.

Le "Traducteur"

Que faire si la cible ne sait pas exposer de /metrics (ex: un serveur Linux, une BDD PostgreSQL, un routeur Cisco) ?

On utilise un **Exporter** : un petit service qui "traduit" l'état d'un système tiers en métriques Prometheus.

Exporters populaires

• node_exporter : Métriques système (CPU, RAM, Disque, Réseau) (pour Linux/Win).
• postgres_exporter : Métriques PostgreSQL.
• mysqld_exporter : Métriques MySQL/MariaDB.
• blackbox_exporter : Monitoring "boîte noire" (Ping, HTTP, DNS).

Exemple : node_exporter

# 1. Télécharger et lancer (sur la cible '1.2.3.4')
wget .../node_exporter-....tar.gz
tar -xvf ...
./node_exporter
# (Expose les métriques sur 1.2.3.4:9100/metrics)

# 2. Configurer Prometheus (prometheus.yml)
scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['1.2.3.4:9100', '1.2.3.5:9100']

Sélecteurs ({})

Comment filtrer les time series.

# 1. Nom de la métrique
http_requests_total

# 2. Nom + Labels (exact)
http_requests_total{job="api", method="GET"}

# 3. Opérateurs de Label
# (!= : différent, =~ : regex, !~ : not regex)
http_requests_total{job="api", method!="POST"}
http_requests_total{path=~"/api/v[12]/.*"}

Vecteurs (Instant vs Range)

Instant Vector (Vecteur Instantané)

Retourne une seule valeur (la plus récente) par time series. C'est le défaut.

node_cpu_usage_percentage
# (Affiche le CPU *maintenant*)

Range Vector (Vecteur de Plage) [5m]

Retourne l'historique des valeurs sur une plage de temps (ex: "les 5 dernières minutes").

node_cpu_usage_percentage[5m]

Attention : Un Range Vector ne peut pas être affiché tel quel. Il doit être passé à une fonction (rate, increase...).

Le problème du "Counter"

Si vous affichez un "Counter" (http_requests_total), le graphe ne fera que monter. Ce n'est pas utile.

Ce qu'on veut, c'est le **taux d'augmentation** (ex: requêtes *par seconde*).

rate()

Calcule le taux d'augmentation *par seconde*, basé sur un Range Vector.

# Calcule le taux de requêtes/seconde,
# moyenné sur les 5 dernières minutes.
rate(http_requests_total[5m])

increase()

Calcule l'augmentation *totale* sur la plage de temps.

# Calcule le nombre total de requêtes
# (pas par sec) des 30 dernières minutes.
increase(http_requests_total[30m])

irate() (Avancé)

rate() moyenne sur 5m (lissé). irate() (instant rate) ne regarde que les 2 derniers points. Utile pour voir les "pics" (spikes).

Opérateurs d'agrégation

(sum, avg, min, max, count, topk...)

# (Input: 100 series de req/sec, 1 par 'path')
rate(http_requests_total[5m])

# (Output: 1 seule valeur = le total)
sum(rate(http_requests_total[5m]))

Clauses by & without (Le "GROUP BY")

# (Input: 100 series avec labels {job, instance, path})
rate(http_requests_total[5m])

# (Output: Req/sec, groupées par 'job' et 'path')
# (Supprime 'instance')
sum(rate(http_requests_total[5m])) by (job, path)

# (Output: Req/sec, groupées par TOUT sauf 'instance')
# (Plus facile si on a 10 labels)
sum(rate(http_requests_total[5m])) without (instance)

topk

# Top 3 des instances par utilisation CPU
topk(3, node_cpu_usage_percentage)

Rôle d'Alertmanager

Prometheus *génère* les alertes (basé sur les règles). Alertmanager (un service séparé) les *gère*.

Rôles clés :

• Dé-duplication : Si 100 serveurs sont "down", ne reçoit qu'une alerte.
• Grouping (Groupage) : Regroupe 100 alertes "DiskFull" en 1 seule notification.
• Routing (Routage) : Envoie les alertes "critical" à PagerDuty, les "warning" à Slack.
• Silencing (Silence) : Permet de taire les alertes (ex: maintenance).

alertmanager.yml

global:
  resolve_timeout: 5m

route:
  # Route racine (défaut)
  receiver: 'slack-default'
  group_by: ['alertname', 'cluster']
  
  # Attendre 1m avant 1ère notif, 1h avant rappel
  group_wait: 1m
  group_interval: 10m
  repeat_interval: 1h

  # Routage spécifique
  routes:
  - receiver: 'pagerduty-critical'
    match:
      severity: 'critical' # (Label de l'alerte)
    
  - receiver: 'slack-warning'
    match:
      severity: 'warning'

receivers:
- name: 'slack-default'
  slack_configs:
  - api_url: 'https://hooks.slack.com/...'
    channel: '#alerts'

- name: 'pagerduty-critical'
  pagerduty_configs:
  - service_key: ...

static_configs (Statique)

Simple, mais rigide. Vous devez lister chaque cible manuellement. Si une IP change, le .yml doit être modifié et Prometheus rechargé (HUP).

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['1.2.3.4:9100', '1.2.3.5:9100']

Service Discovery (Dynamique)

Prometheus peut "découvrir" ses cibles en lisant une source de vérité externe (Consul, Kubernetes API, ou un simple fichier).

file_sd_configs (Fichier SD)

# prometheus.yml
scrape_configs:
  - job_name: 'node'
    file_sd_configs:
      - files:
        - '/etc/prometheus/targets/nodes.json'
      # (Prometheus surveille ce JSON en permanence)
      
# /etc/prometheus/targets/nodes.json
[
  {
    "targets": ["1.2.3.4:9100", "1.2.3.5:9100"],
    "labels": {
      "env": "prod",
      "dc": "datacenter1"
    }
  },
  {
    "targets": ["10.0.0.1:9100"],
    "labels": {
      "env": "staging"
    }
  }
]

Haute Disponibilité (HA)

La méthode HA standard consiste à lancer **deux** serveurs Prometheus identiques, qui scrapent les **mêmes** cibles.

Les deux envoient leurs alertes à Alertmanager, qui s'occupe de la dé-duplication (grâce aux labels identiques).

Grafana est configuré avec les deux serveurs Prometheus comme Data Source (en cas de panne de l'un).

Fédération

Pour agréger les données de plusieurs serveurs Prometheus (ex: un par datacenter) vers un Prometheus "global".

# (Config du Prometheus Global)
scrape_configs:
  - job_name: 'federate-dc1'
    # Scrape le endpoint /federate (optimisé)
    metrics_path: '/federate'
    params:
      'match[]': # Ne récupérer que les métriques agrégées
        - '{job="node"}'
    static_configs:
      - targets: ['prometheus.dc1.internal:9090']

  - job_name: 'federate-dc2'
    ...
    static_configs:
      - targets: ['prometheus.dc2.internal:9090']

Fonctions (Counters)

# Req/sec (moyenne sur 5m)
rate(http_requests_total[5m])

# Augmentation (sur 1h)
increase(http_requests_total[1h])

# Req/sec (pics, basé sur les 2 derniers points)
irate(http_requests_total[1m])

Agrégation

# Total des req/sec, groupées par 'job'
sum(rate(http_requests_total[5m])) by (job)

# CPU moyen (toutes instances)
avg(node_cpu_usage_percentage)

# CPU moyen (sans le label 'core')
avg(node_cpu_usage_percentage) without (core)

# Top 5 des instances par RAM
topk(5, node_memory_usage_bytes)

# Compter le nombre de time series
count(http_requests_total)

Histogrammes (Percentiles)

# 95ème percentile de la latence
histogram_quantile(
  0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, job)
)

# Moyenne (calculée depuis un histogramme)
sum(rate(http_request_duration_seconds_sum[5m])) by (job)
/
sum(rate(http_request_duration_seconds_count[5m])) by (job)

Opérateurs

# Opérateurs (>, <, ==, !=)
node_cpu_usage_percentage > 80

# Arithmétique
# (RAM utilisée en % (Gauge / Gauge))
100 * (node_memory_total_bytes - node_memory_free_bytes) 
  / 
node_memory_total_bytes