Explosion des coûts Thanos S3 en prod help

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

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

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

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 ?

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

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

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

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

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

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 ?

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

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 ?

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

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

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

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

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 !