Prometheus range queries trop lentes sur grosse période

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.

oui sur thanos tu peux aussi optimiser les stores. s3 c'est génial mais si tu as des buckets avec des millions de petits fichiers ça peut ralentir la lecture si tes blocks sont trop petits. `block-duration` est important.

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 !