10 commentaires
yo pour les grosses range queries c'est souvent les cardinality. si t'as trop de labels différents sur tes métriques, prometheus doit bosser comme un fou pour agréguer tout ça. t'as jeté un œil à la métrique prometheus_tsdb_head_series ou prometheus_tsdb_wal_truncated_series ?
et aussi la résolution des points. si tu demandes un rate sur 7j avec une résolution par défaut qui essaie de te retourner des points toutes les 15s ça fait un volume de data énorme. t'as pas moyen d'utiliser un recording rule qui pré-agrège tes rate sur des périodes plus longues genre 1h ou 4h ?
cardinality c'est possible en effet on a pas mal de services et de routes avec des labels. prometheus_tsdb_head_series est autour de 5 millions. pour les recording rules on y a pensé mais ça demande de changer pas mal de dashboards après.
5 millions c'est pas énorme mais ça dépend de ton scrape interval et de ton retention. si tu fais des requêtes sur 7j tu pull des giga de datapoints. regarde la doc de l'api pour les options step ou range pour optimiser. sinon, un truc con mais le query.max-concurrent et query.max-samples dans la config prom ?
en parlant de recording rules, tu peux les faire tourner en parallèle et juste utiliser les métriques pré-agrégées pour tes dashboards longue durée. tes dash courts restent sur les métriques brutes. c'est un compromis. et ouais le step est clé, si tu forces un step=1h pour un mois ça ira bien plus vite.
ok je vais creuser les recording rules plus sérieusement alors. j'avais zappé l'option step dans les requêtes grafana je vais voir si je peux l'appliquer dynamiquement. thx pour les query.max-concurrent aussi je savais pas que ça existait.
et surtout pense à mettre un bon sharding ou utiliser un thanos ou cortex pour distribuer la charge de requêtage et de stockage. prometheus seul c'est top pour le temps réel et le court terme, moins pour les requêtes sur des mois entiers avec des millions de séries.
on est sur thanos déja pour le stockage long terme mais la requête est directement sur le query frontend. je vais essayer de tuner le step d'abord et ptete des recording rules sur thanos compactor. bonne idée.
ok j'ai testé en forçant un step plus grand sur les dash longues périodes et ça va déjà beaucoup mieux. on va implémenter des recording rules pour les métriques clés. thx à tous c'était super utile !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la team prom ! j'ai des dashboards grafana qui utilisent des requêtes de type
rate(http_requests_total[5m])sur des périodes de 7 jours ou un mois et ça rame de ouf. des fois la requête timeout. l'infra prometheus a l'air ok avec des disques ssd et pas mal de cpu/ram. on stocke genre 6 mois de data.