11 commentaires
salut. 100% CPU c'est souvent des requêtes PromQL pas optis ou des grosses cardinalités de labels qui forcent Thanos à scanner trop de données. t'as analysé les requêtes les plus coûteuses ? la query log de Thanos peut aider
oui exactement. et assure-toi que ton Store Gateway est bien configuré pour le downsampling. si t'as pas de downsampling ça veut dire que Query lit toujours des données haute résolution même pour des longues périodes et ça c'est lourd
on utilise le query frontend oui mais il semble pas absorber toute la charge. les requêtes coûteuses sont souvent des count_over_time ou des moyennes sur des périodes de plusieurs jours avec des labels de service importants
sum(rate(http_requests_total{job="my-app", service="api"}[5m])) by (endpoint)
ce genre de truc mais sur des périodes de 1 semaine
pour les longues périodes le downsampling est critique. t'as un compactor qui tourne bien pour générer les blocs 5m et 1h ? sinon Query doit lire tout le raw data
et dans ta config thanos query tu as quoi pour le max-query-parallelism et le query.default-evaluation-interval ? tu peux augmenter le parallelism mais ça consomme plus de cpu par requête mais les finit plus vite
regarde aussi le store.grpc.server-max-recv-msg-size dans les configs des store gateways et query. si les blocs sont gros et que cette limite est trop basse ça peut créer des soucis de fragmentation ou de re-fetch. et le cache d'index dans query est bien configuré ? genre query.cache-index-ttl
ok pour le downsampling on l'avait activé mais le compactor avait des soucis on dirait. il va falloir vérifier ses logs. et je vais regarder les paramètres max-query-parallelism et le cache index. on a 4 de parallelism par défaut. on peut essayer d'augmenter ça à 8
bon j'ai fix le compactor il refait ses blocs 5m/1h. et j'ai augmenté le parallelism à 8. ça a l'air déjà beaucoup mieux. les pics cpu sont moins hauts et la latence est redescendue. je vais surveiller ça mais c'était clairement le compactor qui faisait pas son taff. thx beaucoup !
de rien. la maintenance du compactor est cruciale pour Thanos sinon tu perds tous les avantages du downsampling
Laisser une réponse
Vous devez être connecté pour poster un message !
Hello la team, on est en train de galérer avec notre setup Thanos. On a un Thanos Query qui sert nos dashboards Grafana et des requêtes API. Dès qu'il y a un peu trop de monde qui utilise Grafana ou qu'un script fait beaucoup de requêtes, le Thanos Query prend 100% de CPU et la latence monte en flèche. On a 4 replicas et le problème est sur tous. On utilise S3 comme storage pour les blocs. Des idées pour optimiser ça ?