Multi-tenant et limites

1. Les tenants #

Une isolation logique complète.

Principe #

Dans Mimir, chaque requête porte l'identifiant d'un tenant dans l'en-tête X-Scope-OrgID. Les données, les règles, l'Alertmanager et les limites sont séparés par tenant : une équipe ne voit jamais les séries d'une autre.

multitenancy_enabled: true   # défaut

Erreur Courante : Mimir ne fait pas d'authentification : il fait confiance à l'en-tête. En production, placez devant lui une passerelle (nginx, Envoy, Grafana Enterprise Metrics) qui authentifie le client puis injecte le bon X-Scope-OrgID.

Exemple de passerelle nginx #

map $remote_user $tenant {
  equipe-web      web;
  equipe-data     data;
}
server {
  listen 80;
  auth_basic           "Mimir";
  auth_basic_user_file /etc/nginx/htpasswd;
  location / {
    proxy_set_header X-Scope-OrgID $tenant;
    proxy_pass http://mimir:8080;
  }
}

Requêtes multi-tenant #

Avec tenant_federation.enabled: true, une requête peut viser plusieurs tenants : X-Scope-OrgID: web|data. Le label __tenant_id__ indique alors l'origine de chaque série. Pratique pour une équipe SRE centrale.

2. Les limites #

Protéger le cluster des abus et des erreurs.

Limites d'ingestion #

Un dépassement se traduit par des erreurs 429 ou 400 côté Prometheus et par la métrique cortex_discarded_samples_total{reason=...} côté Mimir.

Erreur Courante : Les valeurs par défaut sont volontairement basses. Le premier « bug » rencontré en production est presque toujours per_user_series_limit : relevez les limites du tenant concerné plutôt que de désactiver le contrôle.

3. La configuration d'exécution #

Changer les limites sans redémarrer.

runtime.yaml #

# mimir.yaml
runtime_config:
  file: /etc/mimir/runtime.yaml
  period: 10s

# runtime.yaml (relu toutes les 10 s)
overrides:
  web:
    ingestion_rate: 50000
    ingestion_burst_size: 1000000
    max_global_series_per_user: 2000000
  data:
    max_global_series_per_user: 500000
    max_fetched_series_per_query: 100000
    ingestion_tenant_shard_size: 6   # shuffle sharding : 6 ingesters seulement

La page /runtime_config affiche les surcharges en vigueur ; /runtime_config?mode=diff montre ce qui diffère des valeurs par défaut.

Shuffle sharding #

Sans shuffle sharding, chaque tenant utilise tous les ingesters et tous les queriers : un tenant qui envoie une requête monstrueuse ralentit tout le monde. En attribuant à chaque tenant un sous-ensemble aléatoire d'instances (ingestion_tenant_shard_size, max_queriers_per_tenant, store_gateway_tenant_shard_size), on limite le rayon d'impact d'un tenant bruyant.

Bonne Pratique : Commencez par mesurer : cortex_ingester_active_series par tenant et la page /ingester/tenants montrent qui consomme quoi.