infra / monitoring-observabilite

Haute disponibilité et scalabilité de la stack monitoring

Leçon 141 exercice

Explication

Ce que vous allez apprendre

Identifier pourquoi un Prometheus unique constitue un point de défaillance critique
Mettre en place une haute disponibilité "naïve" avec deux instances Prometheus identiques
Comprendre le rôle de la fédération pour agréger plusieurs Prometheus régionaux
Ajouter du stockage long terme avec Thanos, sans changer le fonctionnement de Prometheus lui-même
Configurer Alertmanager en cluster pour éviter un point de défaillance sur les notifications

Dans quel contexte ?

La stack de monitoring de l'entreprise tourne parfaitement depuis plusieurs mois... jusqu'au jour où le serveur qui héberge Prometheus tombe en panne matérielle. Pendant les deux heures de restauration, l'équipe perd totalement sa capacité à détecter d'éventuels incidents ailleurs dans l'infrastructure — l'outil censé prévenir des pannes devient lui-même la panne.

D'abord, il faut nommer clairement le problème

Un seul Prometheus qui scrape, évalue les alertes et sert les dashboards est ce qu'on appelle un SPOF (single point of failure, point de défaillance unique) : sa panne coupe TOUT le monitoring d'un coup, précisément au moment où on en aurait le plus besoin pour diagnostiquer un incident plus large.

Plusieurs niveaux de solution existent, du plus simple au plus complexe, et le bon choix dépend directement de la taille de l'infrastructure à couvrir.

Solution	Complexité	Résout	Nécessaire à partir de
HA naïf (2 instances identiques)	Faible	Panne d'un serveur Prometheus	Toute production sérieuse
Fédération	Moyenne	Agrégation multi-région/multi-cluster	Plusieurs datacenters/clusters
Thanos / Cortex / Mimir	Élevée	Rétention longue + requêtes globales	Grande échelle, conformité long-terme

Prérequis

Cette leçon suppose que Prometheus et Alertmanager tournent déjà en mode "single instance" dans les leçons précédentes ; elle explique comment faire évoluer cette configuration vers une architecture résiliente.

La solution la plus simple à mettre en place en premier : dupliquer

Deux instances Prometheus, configurées de façon strictement identique et scrapant les mêmes cibles en parallèle, suffisent déjà à survivre à la panne d'une seule d'entre elles. La seule nuance à ajouter est un external_labels: replica distinct par instance, pour qu'un système en aval (Alertmanager, Thanos) puisse identifier que deux séries quasi identiques viennent en réalité de deux réplicas du même monitoring.

Une fois cette base posée, il reste un problème différent : plusieurs clusters ou régions séparés

Dans une infrastructure répartie sur plusieurs datacenters, chaque site a souvent son propre Prometheus local, pour limiter la latence de scraping. La fédération permet à un Prometheus "global" de venir scraper des métriques déjà agrégées depuis ces Prometheus régionaux, via un endpoint spécial /federate.

Piège fréquent

Fédérer sans filtre match[] revient à dupliquer TOUTES les séries de chaque Prometheus régional vers le Prometheus global, créant une explosion de volume inutile. Ne fédérer QUE les séries réellement nécessaires à une vue globale (souvent déjà pré-agrégées via des recording rules) est indispensable pour que la fédération reste gérable.

Maintenant, un problème que ni la duplication ni la fédération ne résolvent : la rétention longue

Prometheus, par conception, n'est pas fait pour stocker des données pendant des années : son TSDB local reste limité en pratique. Thanos (ou ses équivalents Cortex, Mimir) attache un stockage objet externe (S3, GCS) à chaque Prometheus via un sidecar, sans changer son fonctionnement de scraping habituel.

Bonne pratique

Ne configure jamais Alertmanager en instance unique dans une architecture qui vise la haute disponibilité : ce serait déplacer le SPOF de Prometheus vers Alertmanager, sans rien résoudre. Un cluster d'au moins 3 noeuds Alertmanager, synchronisés par gossip protocol, garantit qu'une seule notification part même si plusieurs Prometheus envoient la même alerte.

La stack de monitoring elle-même est désormais robuste. Il reste une dernière compétence essentielle avant de la considérer prête pour la production réelle : maîtriser ses coûts et sa cardinalité, sujet de la prochaine leçon.

Commandes & code

Haute disponibilité et scalabilité de la stack monitoring

Problème : un seul Prometheus = un SPOF (single point of failure) pour TOUT le monitoring.
Solutions à différents niveaux de complexité :

1. Prometheus HA "naïf"    -> 2 instances identiques, scrapant les mêmes cibles en parallèle
2. Federation                -> un Prometheus "global" scrape des agrégats depuis des Prometheus "locaux"
3. Remote write + Thanos/Cortex/Mimir -> stockage long-terme partagé, requêtes globales dédupliquées

# 1. HA naïf : deux Prometheus indépendants, même config, derrière un load balancer pour les dashboards
# prometheus-1.yml et prometheus-2.yml sont IDENTIQUES
global:
  external_labels:
    replica: "prometheus-1"     # label distinctif, nécessaire pour la déduplication en aval (Thanos)

scrape_configs:
  - job_name: "mon_api"
    static_configs:
      - targets: ["mon-api-1:8000", "mon-api-2:8000"]
# -> Alertmanager déduplique nativement les alertes identiques venant des 2 Prometheus (cluster mode, voir plus bas)

# 2. Federation : un Prometheus "global" scrape des métriques déjà agrégées depuis des Prometheus régionaux
# prometheus-global.yml
scrape_configs:
  - job_name: "federate"
    scrape_interval: 30s
    honor_labels: true                  # conserve les labels d'origine plutôt que ceux du scrape
    metrics_path: "/federate"
    params:
      "match[]":
        - '{job="api"}'                  # ne fédère QUE les séries utiles (pas tout, pour limiter le volume)
    static_configs:
      - targets:
          - "prometheus-eu:9090"
          - "prometheus-us:9090"

# 3. Thanos Sidecar : attache le stockage long-terme (S3/GCS) à chaque Prometheus, sans changer son fonctionnement
services:
  thanos-sidecar:
    image: thanosio/thanos:v0.36.0
    command:
      - "sidecar"
      - "--tsdb.path=/prometheus"
      - "--prometheus.url=http://prometheus:9090"
      - "--objstore.config-file=/etc/thanos/objstore.yml"
    volumes:
      - prometheus_data:/prometheus
      - ./objstore.yml:/etc/thanos/objstore.yml:ro

  thanos-query:
    image: thanosio/thanos:v0.36.0
    command:
      - "query"
      - "--store=thanos-sidecar-1:10901"
      - "--store=thanos-sidecar-2:10901"    # interroge PLUSIEURS sidecars, déduplique via external_labels

# Alertmanager en cluster (HA native, pas de dépendance à un stockage partagé)
# alertmanager.yml lancé sur 3 noeuds avec --cluster.peer pointant les uns vers les autres
# Commande de lancement (résumé) :
# alertmanager --cluster.peer=alertmanager-2:9094 --cluster.peer=alertmanager-3:9094
global:
  resolve_timeout: 5m
route:
  receiver: "default-slack"
# -> les 3 instances se synchronisent via gossip protocol : une seule notification part, même si 3 Prometheus
#    envoient la même alerte

# Remote write : Prometheus local envoie ses données vers un stockage centralisé (Mimir, Cortex, VictoriaMetrics)
# prometheus.yml
# remote_write:
#   - url: "http://mimir:9009/api/v1/push"
#     queue_config:
#       max_samples_per_send: 5000
#       max_shards: 30

# Avantage : rétention longue (années) sans surcharger chaque Prometheus local, requêtes globales cross-cluster

Résumé

Deux Prometheus identiques + Alertmanager en cluster (gossip) suffisent pour une HA basique sans complexité supplémentaire.
La federation limite le volume transmis en agrégeant AVANT de remonter au niveau global (match[] sélectif obligatoire).
Thanos/Cortex/Mimir ajoutent stockage long-terme partagé (S3/GCS) et déduplication cross-replica : nécessaire à grande échelle, pas pour un petit cluster.
external_labels (ex: replica) est le mécanisme qui permet à Alertmanager et Thanos de dédupliquer des données identiques venant de plusieurs sources.

Exercices pratiques

1 disponible

Mission : le monitoring qui surveille le monitoring

Objectif : Concevoir une architecture Prometheus/Alertmanager résiliente à la panne d'une seule instance, sans déplacer le SPOF ailleurs.

Contexte

Le seul serveur Prometheus de l'entreprise vient de tomber en panne matérielle pendant deux heures. Pendant ce temps, un incident réel sur payment-api n'a été détecté par personne. L'équipe veut désormais une architecture qui survit à la panne d'un seul composant, sans sur-ingénierie inutile pour une infrastructure encore modeste (un seul datacenter).

Résoudre l’exercice →