Mimir : le chemin d'écriture (distributor, ingesters, réplication et déduplication HA)

1. Envoyer des métriques à Mimir #

Remote write, OTLP et tenant.

Configurer Prometheus #

Prometheus continue de collecter (ou passe en mode agent, sans stockage local ni requêtes) et pousse ses échantillons vers Mimir.

# prometheus.yml
global:
  scrape_interval: 15s
  external_labels:
    cluster: prod-eu      # identifie la source
    __replica__: replica-a  # identifie le réplica HA (retiré par Mimir)

remote_write:
  - url: http://mimir:8080/api/v1/push
    headers:
      X-Scope-OrgID: team-platform   # tenant
    queue_config:
      capacity: 10000
      max_samples_per_send: 2000
      max_shards: 50

À savoir : Avec multitenancy_enabled: false, l'en-tête X-Scope-OrgID est inutile : toutes les données vont dans le tenant anonymous.

Avec Grafana Alloy #

prometheus.remote_write "mimir" {
  endpoint {
    url     = "http://mimir:8080/api/v1/push"
    headers = { "X-Scope-OrgID" = "team-platform" }
  }
}

2. Distributor et ingesters #

Valider, répartir, répliquer.

Le parcours d'un échantillon #

1. Le distributor vérifie le tenant, la validité des labels (nombre, longueur, noms), l'horodatage et applique les limites d'ingestion. Un dépassement renvoie 429 (limite de débit) ou 400 (échantillon invalide).
2. Il hache tenant + labels pour trouver, dans le ring, les 3 ingesters (facteur de réplication par défaut) responsables de la série.
3. Chaque ingester ajoute l'échantillon à sa TSDB en mémoire et l'écrit dans son WAL (write-ahead log) sur disque, pour survivre à un redémarrage.
4. Toutes les 2 heures, l'ingester ferme un bloc TSDB et le téléverse dans le stockage objet. Il garde les blocs récents localement pour répondre aux requêtes (13 h par défaut).

Réplication et quorum #

Avec un facteur de réplication de 3, l'écriture est confirmée dès que 2 ingesters sur 3 ont répondu. On peut donc perdre un ingester (ou une zone entière avec la réplication par zone) sans perte de données ni erreur côté client.

ingester:
  ring:
    replication_factor: 3
    zone_awareness_enabled: true    # une copie par zone de disponibilité
    instance_availability_zone: zone-a

Erreur Courante : Les ingesters sont avec état : déployez-les en StatefulSet avec un volume persistant pour le WAL, et redémarrez-les un par un (ou une zone à la fois). Supprimer plusieurs ingesters d'un coup peut faire perdre les données non encore téléversées.

3. Déduplication des paires Prometheus HA #

Deux réplicas, une seule série stockée.

Principe #

Pour la haute disponibilité, on lance deux Prometheus identiques. Sans précaution, Mimir stockerait chaque série deux fois. Le HA tracker du distributor élit, pour chaque couple (tenant, cluster), un réplica « leader » et rejette les échantillons de l'autre. Si le leader se tait plus de ha_tracker_failover_timeout (30 s par défaut), l'autre prend le relais.

# mimir.yaml
limits:
  accept_ha_samples: true
  ha_cluster_label: cluster        # valeurs par défaut
  ha_replica_label: __replica__

distributor:
  ha_tracker:
    enable_ha_tracker: true
    kvstore:
      store: consul
      consul:
        host: consul:8500

Bonne Pratique : Les deux Prometheus doivent avoir la même valeur pour cluster et une valeur différente pour __replica__. Mimir retire le label de réplica avant le stockage.

La page /distributor/ha_tracker montre le réplica élu pour chaque cluster. La métrique cortex_distributor_deduped_samples_total compte les échantillons écartés.