Explosion des coûts Thanos S3 en prod help

Question

yo la commu, on a un gros souci de finops avec thanos. notre facture s3 a explosé le mois dernier genre x3. on stocke genre 2 ans de métriques et la cardinalité de certaines séries est juste insane. je pense aux labels dynamic générés par des services qui ont des IDs uniques. on utilise thanos sidecar et compact. comment on peut réduire ça sans perdre trop d'historique ? on est sous aws
#thanos compact config example (simplified)
compaction:
  retention_resolution_raw: 7d
  retention_resolution_5m: 30d
  retention_resolution_1h: 2y
block_sync_concurrency: 20

on a déjà essayé de virer quelques labels inutiles mais ça n'a pas suffi. est-ce qu'il y a un moyen de downsampler plus agressivement ou de droper certaines séries à haute cardinalité avant qu'elles arrivent à s3 ?

xlegrand · Answer

salut ! les coûts S3 Thanos c'est un classique. la première chose à regarder c'est vraiment la cardinalité. t'as déjà identifié les métriques qui génèrent le plus de séries ? thanos tools bucket web peut t'aider à visualiser ça

zbourdon · Answer

oui on a vu certaines métriques métier qui ont un label request_id ou session_id et ça c'est la mort. on a des millions de séries pour certaines

xlegrand · Answer

million de séries avec des request_id c'est le suicide de la perf et du coût. ces labels là n'ont rien à faire dans des métriques long terme. ils devraient être dans les logs ou les traces. pas dans prometheus/thanos

zbourdon · Answer

je sais bien mais c'est des métriques existantes qu'on a juste branchées. comment je peux les droper ou les ré-écrire avant que ça aille dans thanos ?

xlegrand · Answer

pour ça t'as plusieurs options. la plus simple c'est de faire du relabeling au niveau du Prometheus qui scrape ces métriques. tu peux soit droper la métrique entièrement, soit droper le label spécifique

zbourdon · Answer

ok relabeling à la source ça me parle. tu aurais un exemple de config qui drop un label précis avant ingestion ?

xlegrand · Answer

oui bien sûr. par exemple pour droper le label request_id de toutes les métriques qui le contiennent :
- job_name: 'my_app_metrics'
  static_configs:
    - targets: ['localhost:8080']
  relabel_configs:
    - source_labels: [__name__]
      regex: 'my_metric_with_request_id_.*'
      action: keep
    - source_labels: [request_id]
      regex: '.*'
      action: labeldrop
ça drop request_id sur toutes les métriques

zbourdon · Answer

intéressant ! et si je veux carrément droper toutes les métriques qui ont ce label ?

xlegrand · Answer

dans ce cas tu peux faire ça :
- job_name: 'my_app_metrics'
  static_configs:
    - targets: ['localhost:8080']
  relabel_configs:
    - source_labels: [request_id]
      regex: '.+'
      action: drop
ça dropera toutes les séries qui ont un label request_id non vide

zbourdon · Answer

ok ça c top ! ça va grandement réduire l'ingestion je pense. autre question, le downsampling du compact. on a 7j raw, 30j 5m, 2y 1h. c standard ou on peut faire plus agressif ?

xlegrand · Answer

pour la rétention downsamplée, 2y en 1h c'est standard. mais tu peux jouer sur le retention_resolution_5m pour le réduire genre à 15j si tu n'as pas besoin de la granularité 5m au-delà de deux semaines. ça réduirait la taille des blocs 5m

zbourdon · Answer

genre passer le 5m à 15j et laisser le 1h à 2y. ok ça a du sens. et pour les blocs bruts, 7j c'est le minimum je pense pour le dépannage rapide ?

xlegrand · Answer

7j raw c'est un bon compromis pour le dépannage. tu pourrais le baisser à 3j mais c'est souvent trop court pour des investigations. il faut trouver le juste milieu entre coût et capacité de débug

zbourdon · Answer

d'acc. je vais implémenter le relabeling pour droper les request_id et réduire le retention_resolution_5m à 15j. ça devrait déjà bien soulager le bucket S3

xlegrand · Answer

oui ça va faire une énorme différence. n'oublie pas que les blocs déjà écrits ne disparaîtront pas tout de suite, le compactor va les gérer avec le temps. mais l'ingestion va chuter drastiquement

zbourdon · Answer

ok compris. je vais monitorer le coût S3 et la taille du bucket dans les jours/semaines à venir. thx un max pour tous ces conseils super précis c'est ce qu'il me fallait

zbourdon · Answer

bon après deux semaines avec les règles de relabeling et la réduction de la rétention 5m, notre coût S3 a chuté de 40% et l'ingestion aussi. c'est énorme. un grand merci pour l'aide !

Explosion des coûts Thanos S3 en prod help

17 commentaires

Laisser une réponse

Notre première infrastructure AWS depuis Terraform

Les variables CI/CD dans GitLab pour gérer vos secrets

L'IA au Service du Flow: Le Neuro-DevOps pour une Productivité Inégalée

OOMKiller : Comment identifier et stopper vos fuites mémoire

Sécurisez vos secrets Kubernetes en 5 minutes chrono

Rejoindre la communauté