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?

alors... il est à 2h. c'est la config par défaut que j'ai laissée.

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`?

`retention.resolution-raw` est à 7j et `retention.resolution-5m` à 30j.

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.

non il n'est pas activé. j'ai bien les résolutions différentes.

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?

oh putain... oui on a un service mesh qui met des `request_id` sur certaines metrics pour du tracing. c'est horrible je sais mais c'est l'équipe dev qui a demandé.

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.

ok d'acc. je vais faire ça: changer le `block-duration` à 24h, réduire la `retention` raw à 2j et surtout, je vais intégrer une `metric_relabel_config` pour virer ce `request_id` pourri de nos labels. c'est bon je pense.

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.

d'acc. je vais surveiller ça de près et mettre en place les policies s3. gros merci les gars pour toutes ces infos super utiles!