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).
