20 commentaires
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 ?
j'ai pas touché à la concurrence du compactor c'est les defaults. on a des blocks de 2h
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
3 instances store gateway r5.xlarge. elles sont pas en pleine charge mais quand on fait des requêtes complexes ça rame
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
quelle taille de cache pour les store gateways vous recommandez. on est à 256mb par défaut je crois
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
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 !
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