thanos store/compactor costs qui explosent
Commentaires
salut. si tes coûts s3 explosent c'est que tu stockes trop de raw data ou que ton downsampling est pas assez agressif. tes retentions semblent ok mais peut-être que 7j de raw c'est trop
on a pas mal de métriques à haute cardinalité. ptete un souci là aussi mais on doit garder le raw pour le debugging précis
le raw c'est cher. pour le finops il faut vraiment limiter. avez-vous des métriques qui ne sont jamais interrogées en raw après un certain temps ?
exacte. tu peux aussi jouer sur le --compactor.block-sync-concurrency et le --compactor.block-upload-concurrency pour optimiser la vitesse de compactage et libérer les instances plus vite
j'ai pas touché à la concurrence du compactor c'est les defaults. on a des blocks de 2h
2h c'est standard. est-ce que tu utilises un lifecycle policy sur ton bucket S3 pour passer les vieilles données en Infrequent Access ou Glacier après un certain temps ? ça réduit grave les coûts de stockage
oui clairement. ça c'est une des premières optimisations coût à faire. après 30j par exemple Infrequent Access et après 90j Glacier Deep Archive si t'en as besoin juste pour audit ou compliance
on a pas de lifecycle policy encore. bonne idée. mais pour la latence des query sur les longues périodes ça améliore pas ça
non la lifecycle policy c'est pour le stockage. pour la latence des query c'est plutôt tes store gateway. tu as combien d'instances de store gateway ? elles ont assez de cpu/mem ?
3 instances store gateway r5.xlarge. elles sont pas en pleine charge mais quand on fait des requêtes complexes ça rame
pour les requêtes lentes sur les données downsamplées tu peux pré-aggréger des métriques importantes avec Thanos Ruler ou faire du caching sur tes query frontends
le caching est vital pour les dashboards ou rapports qui tapent souvent sur les mêmes plages historiques. sinon tu payes cher chaque lecture S3
on a pas de ruler encore. tout est à la volée. le caching c'est une option oui. je vais regarder memcached ou redis
y a des soucis de perfs sur les store gateway si elles doivent charger trop de blocks simultanément pour une query. tu peux augmenter le --store.sync-block-duration si tu as une forte latence S3 ou augmenter la taille du cache store gateway
quelle taille de cache pour les store gateways vous recommandez. on est à 256mb par défaut je crois
pour r5.xlarge tu peux facilement monter à 4-8GB de cache pour le store. ça réduira les appels S3 pour les blocks fréquemment accédés
et si tu as des métriques vraiment pas critiques tu peux carrément les virer de Thanos et les envoyer dans un autre système de logs moins cher après 30j. genre les logs détaillés de chaque pod
ok donc lifecycle policies sur S3 augmenter cache store gateway et ptete ruler pour les métriques critiques. j'ai déjà des pistes pas mal
n'oublie pas de vérifier ta cardinalité aussi avec les outils comme thanos tools bucket web pour identifier les séries qui coûtent cher. ça peut être une étiquette mal configurée
top merci beaucoup pour tous ces conseils je vais pouvoir attaquer tout ça. ça va faire du bien au budget et à la patience des équipes
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
philippe68
Membre depuis le 02/04/2019
actif
hello les gars on a un souci avec thanos nos s3 buckets sont énormes et les instances store et compactor coutent un bras. on a des query qui tapent sur des années de data et c'est lent et cher. on cherche des pistes pour optimiser les coûts et la perf