Mimir : compactor, rétention et stockage objet

1. Configurer le stockage objet #

Trois buckets distincts.

Configuration commune #

Mimir stocke trois choses dans le stockage objet : les blocs de métriques, les règles du ruler et la configuration de l'Alertmanager. Utilisez trois buckets (ou trois préfixes) différents.

common:
  storage:
    backend: s3
    s3:
      endpoint: minio:9000
      access_key_id: mimir
      secret_access_key: supersecret
      insecure: true

blocks_storage:
  s3: { bucket_name: mimir-blocks }
  tsdb: { dir: /data/tsdb }
  bucket_store: { sync_dir: /data/tsdb-sync }

ruler_storage:
  s3: { bucket_name: mimir-ruler }

alertmanager_storage:
  s3: { bucket_name: mimir-alertmanager }

Erreur Courante : Mimir refuse de démarrer si les blocs et les règles partagent le même bucket sans préfixe : leurs arborescences se mélangeraient.

À savoir : Backends disponibles : s3 (AWS et compatibles : MinIO, Ceph, Scaleway, OVH...), gcs, azure, swift et filesystem (tests uniquement).

2. La compaction #

Moins de blocs, moins de doublons, des requêtes plus rapides.

Pourquoi compacter ? #

Chaque ingester produit un bloc toutes les 2 h ; avec 30 ingesters et un facteur de réplication de 3, cela fait des centaines de petits blocs contenant chacun des doublons. Le compactor :

• fusionne verticalement les blocs d'une même période (et déduplique les échantillons répliqués) ;
• fusionne horizontalement les périodes adjacentes (2 h → 12 h → 24 h) ;
• découpe les très gros tenants en plusieurs blocs (split-and-merge), pour paralléliser ;
• met à jour le bucket index et marque puis supprime les blocs remplacés ou expirés.

Réglages #

compactor:
  data_dir: /data/compactor
  block_ranges: [2h, 12h, 24h]
  compaction_interval: 1h
  deletion_delay: 12h            # délai avant suppression physique d'un bloc remplacé
  sharding_ring:
    kvstore: { store: memberlist }

limits:
  compactor_split_and_merge_shards: 0   # > 0 pour les très gros tenants
  compactor_split_groups: 1

Bonne Pratique : Surveillez cortex_compactor_last_successful_run_timestamp_seconds : un compactor bloqué ne provoque pas d'erreur visible tout de suite, mais les requêtes ralentissent et le stockage gonfle.

3. Rétention et suppression #

Garder ce qu'il faut, le temps qu'il faut.

Rétention #

La rétention est appliquée par le compactor, globalement ou par tenant. Par défaut elle est infinie (0).

limits:
  compactor_blocks_retention_period: 1y

# runtime.yaml : surcharges par tenant
overrides:
  team-dev:
    compactor_blocks_retention_period: 30d
  team-finance:
    compactor_blocks_retention_period: 5y

À savoir : Mimir ne fait pas de downsampling (contrairement à Thanos). Une rétention longue reste raisonnable grâce au prix du stockage objet, mais les requêtes sur plusieurs mois profitent beaucoup de règles d'enregistrement qui pré-agrègent les données.

Supprimer des séries #

Mimir ne propose pas de suppression ciblée de séries : une donnée envoyée par erreur disparaît avec la rétention. Filtrez donc en amont (write_relabel_configs) les labels sensibles. Pour supprimer un tenant entier, utilisez l'API /compactor/delete_tenant.

curl -X POST -H 'X-Scope-OrgID: team-old' http://mimir:8080/compactor/delete_tenant
curl -H 'X-Scope-OrgID: team-old' http://mimir:8080/compactor/delete_tenant_status