1. Le parcours d'une requête #
Du dashboard aux blocs.
Schéma #
- Grafana envoie une requête PromQL à
/prometheus/api/v1/query_range. - Le query-frontend la découpe par intervalle de temps (24 h par défaut) et, si possible, par shard ; il sert depuis son cache les morceaux déjà calculés.
- Les sous-requêtes passent par la file du query-scheduler, qui garantit l'équité entre tenants.
- Un querier évalue chaque sous-requête : il lit les données récentes dans les ingesters et l'historique via les store-gateways.
- Le query-frontend assemble les résultats et les met en cache.
Qui sert quelles données ? #
| Paramètre | Défaut | Effet |
|---|---|---|
querier.query_store_after | 12h | Au-delà, le querier interroge les store-gateways |
querier.query_ingesters_within | 13h | En deçà, il interroge les ingesters |
blocks_storage.tsdb.retention_period | 13h | Durée pendant laquelle l'ingester garde ses blocs localement |
Erreur Courante : Ces trois valeurs sont liées. Si vous réduisez la rétention locale des ingesters sans réduire query_ingesters_within, une partie des données récentes devient invisible.2. Store-gateway et caches #
Lire le stockage objet sans le saturer.
Le store-gateway #
Le store-gateway ne télécharge pas les blocs entiers : il garde localement un index-header (une petite partie de l'index de chaque bloc) et ne lit à distance que les portions utiles. Les blocs sont répartis entre store-gateways via leur propre ring, avec réplication (3 par défaut).
Il s'appuie sur le bucket index, un fichier par tenant maintenu par le compactor qui liste les blocs : inutile de lister le bucket à chaque requête.
Les quatre caches #
| Cache | Utilisé par | Contenu |
|---|---|---|
| results | query-frontend | Résultats de sous-requêtes |
| index | store-gateway | Postings et séries de l'index |
| chunks | store-gateway | Morceaux de données |
| metadata | store-gateway, querier, compactor | Listes de blocs, méta-données |
blocks_storage:
bucket_store:
index_cache:
backend: memcached
memcached: { addresses: dns+memcached-index.mimir.svc:11211 }
chunks_cache:
backend: memcached
memcached: { addresses: dns+memcached-chunks.mimir.svc:11211 }
metadata_cache:
backend: memcached
memcached: { addresses: dns+memcached-metadata.mimir.svc:11211 }
frontend:
results_cache:
backend: memcached
memcached: { addresses: dns+memcached-results.mimir.svc:11211 }
cache_results: trueBonne Pratique : En production, les caches font souvent la différence entre une requête de 30 s et une requête de 300 ms. Le chart Helm sait déployer les quatre memcached.
3. Protéger le chemin de lecture #
Limites de requêtes.
Limites utiles #
| Limite | Rôle |
|---|---|
max_fetched_series_per_query | Plafonne le nombre de séries lues par requête |
max_fetched_chunk_bytes_per_query | Plafonne le volume de données lues |
max_total_query_length | Plafonne la plage de temps d'une requête |
max_query_parallelism | Nombre de sous-requêtes exécutées en parallèle par tenant |
max_queriers_per_tenant | Shuffle sharding : isole un tenant bruyant sur un sous-ensemble de queriers |
Ces limites se règlent globalement dans limits et par tenant dans la configuration d'exécution (voir la leçon sur le multi-tenant).
Mon suivi
Connectez-vous pour suivre votre progression et prendre des notes. Se connecter
💬 Questions sur cette leçon
Aucune question pour l'instant : soyez le premier à demander de l'aide ou à partager votre configuration.
Articles recommandés
Mimir : le chemin d'écriture (distributor, ingesters, réplication et déduplication HA)
Comment Mimir ingère les métriques : remote_write, validation et limites du distributor, hash rin...
Mimir : compactor, rétention et stockage objet
Configurer le stockage objet de Mimir (S3, GCS, Azure, MinIO), comprendre la compaction et le spl...
Bonnes pratiques Grafana Mimir : architecture, limites, coûts et exploitation
Check-list de production pour Grafana Mimir : architecture, réplication par zone, limites par ten...
Pourquoi Grafana Mimir ? Architecture et modes de déploiement
Les limites de Prometheus seul, ce qu'apporte Mimir (stockage long terme, haute disponibilité, mu...
Thanos Query et Query Frontend : une vue globale et dédupliquée
Configurer Thanos Query : endpoints StoreAPI, déduplication par replica label, partial response, ...
Architecture et déploiement de Grafana Pyroscope
Les composants de Pyroscope (distributor, ingester, querier, store-gateway, compactor), le stocka...
Bonnes pratiques Thanos : architecture, stockage, requêtes et exploitation
Bonnes pratiques Thanos : adopter les composants progressivement, labels externes, objstore, comp...
La stack LGTM (Loki, Grafana, Tempo, Mimir) : architecture et mise en place
Comprendre la stack LGTM de Grafana Labs : Loki pour les logs, Grafana pour la visualisation, Tem...
Mimir : ruler, Alertmanager et mimirtool
Évaluer des règles d'enregistrement et d'alerte dans Mimir, configurer l'Alertmanager multi-tenan...