TP : Dédupliquer deux Prometheus en haute disponibilité avec correction

Ce que vous allez apprendre dans ce TP

• Configurer les labels HA
• Activer le HA tracker
• Observer la bascule

Introduction #

Ce que vous allez apprendre dans cette section

• Configurer les labels HA
• Activer le HA tracker
• Observer la bascule

Contexte. Pour ne plus perdre de métriques lors des redémarrages de Prometheus, l'équipe en lance deux identiques. Il faut éviter de stocker (et payer) chaque série deux fois.

Prérequis : TP précédent terminé  ·  Durée estimée : 40 min

Haute disponibilité de la collecte sans doublons.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Ajouter Consul

   Pourquoi ? Le HA tracker doit partager l'élection du leader entre tous les distributors : il lui faut un magasin clé-valeur (Consul ou etcd).

   Ajoutez un service Consul au Compose.
   Voir la correction

     consul:
       image: hashicorp/consul:latest
       command: agent -dev -client=0.0.0.0

2. 2. Activer le HA tracker

   Pourquoi ? Sans lui, Mimir accepterait les deux flux et refuserait une partie des échantillons comme doublons ou hors ordre.

   Complétez mimir.yaml pour accepter les échantillons HA et stocker l'élection dans Consul.
   Voir la correction

   limits:
     accept_ha_samples: true
   distributor:
     ha_tracker:
       enable_ha_tracker: true
       kvstore:
         store: consul
         consul: { host: consul:8500 }

3. 3. Deux Prometheus jumeaux

   Pourquoi ? Même cluster, __replica__ différent : c'est ce couple de labels qui permet l'élection.

   Créez prom-a.yml et prom-b.yml identiques sauf la valeur de __replica__, et deux services Prometheus.
   Voir la correction

   # prom-a.yml (prom-b.yml : __replica__: b)
   global:
     scrape_interval: 15s
     external_labels: { cluster: lab, __replica__: a }
   scrape_configs:
     - job_name: mimir
       static_configs: [{ targets: ["mimir:8080"] }]
   remote_write:
     - url: http://mimir:8080/api/v1/push

     prom-a:
       image: prom/prometheus:latest
       volumes: ["./prom-a.yml:/etc/prometheus/prometheus.yml"]
     prom-b:
       image: prom/prometheus:latest
       volumes: ["./prom-b.yml:/etc/prometheus/prometheus.yml"]

4. 4. Observer l'élection

   Pourquoi ? On vérifie qu'un seul réplica est retenu et que l'autre est bien écarté, pas rejeté en erreur.

   Consultez la page du HA tracker et la métrique des échantillons dédupliqués.
   Voir la correction

   curl -s localhost:8080/distributor/ha_tracker | grep -A2 lab
   curl -sG localhost:8080/prometheus/api/v1/query --data-urlencode 'query=sum(rate(cortex_distributor_deduped_samples_total[1m]))'

5. 5. Provoquer une bascule

   Pourquoi ? Le vrai test de la haute disponibilité : arrêter le leader et constater que les données continuent d'arriver.

   Arrêtez le Prometheus élu, attendez 30 s, puis vérifiez que l'autre réplica a pris le relais et qu'il n'y a pas de trou dans up{job="mimir"}.
   Voir la correction

   docker compose stop prom-a
   sleep 40
   curl -s localhost:8080/distributor/ha_tracker | grep -A2 lab   # le réplica b est élu
   docker compose start prom-a

Niveau de difficulté : ●●●○○ (3/5)