Explosion des coûts S3 Thanos Compactor

hello! ouais c'est un classique. la plupart du temps c'est lié à ton block-duration dans la config du thanos ruler ou thanos sidecar. il est à combien chez toi?

2h c'est trop court pour des grosses infras et des coûts S3 bas. chaque block c'est un objet S3. plus tu as de blocks, plus tu as d'objets, plus le compactor doit faire d'ops S3 pour les compacter/downsampler. passe à 24h ou 48h.

exact. moins de blocks = moins de requêtes S3, moins de coûts. et ça réduit aussi la charge CPU/RAM du compactor.

vérifie aussi tes politiques de rétention. si tu gardes trop longtemps les données raw (haute résolution), ça va vite. t'as quoi pour retention.resolution-raw et retention.resolution-5m?

7j de raw c'est potentiellement trop si t'as une grosse ingeste de metrics. essaie de réduire ça à 2j ou 3j si c'est pas absolument critique pour tes analyses court terme.

et t'as pas downsampling.disable activé dans ta config par hasard? ça empêche le compactor de créer les agrégats et ça peut aussi influer sur le volume des blocs.

un autre classique qui tue les coûts: la cardinalité. tu as des metrics avec des labels qui changent tout le temps? genre request_id ou des timestamps en label?

BOUM! Trouvé! request_id en label c'est un tueur absolu de perf et de coûts. Chaque valeur unique de ce label crée une nouvelle timeseries. Ça génère une explosion de blocks et de métadonnées. C'est la priorité numéro 1 à virer. utilise metric_relabel_configs dans Prometheus pour supprimer ce label avant l'ingestion.

oui le request_id en label c'est la pire chose que tu puisses faire pour Thanos et Prometheus. c'est le truc le plus impactant pour le FinOps.

une fois que tu auras viré ce label et augmenté la block-duration, le compactor va commencer à fusionner les petits blocks en plus gros. ça prendra du temps et un peu de ressources, mais la facture S3 diminuera.

parfait. une fois les changements appliqués, le compactor va faire son boulot. ça peut prendre plusieurs jours avant de voir un impact significatif sur tes coûts S3 car il doit traiter tout l'historique.

et si t'es sur AWS, pense aux Lifecycle Policies S3 pour transitionner les blocks les plus anciens vers des tiers de stockage moins chers comme Standard-IA ou Glacier Deep Archive après quelques mois. ça peut aider sur la rétention long terme.