TP : Tenants, limites et configuration d'exécution

Ce que vous allez apprendre dans ce TP

• Activer le multi-tenant
• Poser une limite par tenant
• Modifier une limite sans redémarrer

Introduction #

Ce que vous allez apprendre dans cette section

• Activer le multi-tenant
• Poser une limite par tenant
• Modifier une limite sans redémarrer

Contexte. Deux équipes partagent désormais Mimir. L'équipe « data » envoie une métrique à très forte cardinalité qui menace le cluster : vous isolez les équipes et posez des limites.

Prérequis : TP 1 terminé  ·  Durée estimée : 40 min

Isoler les équipes et protéger le cluster.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Activer le multi-tenant et la configuration d'exécution

   Pourquoi ? L'en-tête de tenant n'a d'effet que si le multi-tenant est activé ; le fichier d'exécution permet ensuite d'ajuster les limites à chaud.

   Passez multitenancy_enabled à true, déclarez un fichier runtime.yaml relu toutes les 10 s et montez-le dans le conteneur.

2. 2. Envoyer au nom de deux tenants

   Pourquoi ? Chaque équipe doit s'identifier ; l'en-tête est injecté par Prometheus.

   Ajoutez headers: { X-Scope-OrgID: web } au remote_write du Prometheus existant, puis générez des séries pour le tenant data avec l'outil avalanche.

3. 3. Constater le dépassement

   Pourquoi ? Avant de corriger, il faut savoir lire le symptôme : erreurs 400/429 côté client et raison du rejet côté Mimir.

   Retrouvez la raison du rejet dans les métriques de Mimir.

4. 4. Vérifier l'isolation

   Pourquoi ? Le tenant web ne doit ni voir les séries de data ni subir son dépassement.

   Comptez les séries visibles pour chaque tenant.

5. 5. Relever la limite à chaud

   Pourquoi ? En production, on ne redémarre pas Mimir pour ajuster une limite : la configuration d'exécution est relue automatiquement.

   Passez la limite du tenant data à 10 000 séries et vérifiez qu'elle est prise en compte.

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