1. Shards #
Le premier facteur.
Dimensionnement #
- Viser 10 à 50 Go par shard primaire pour les logs ; le rollover par
max_primary_shard_sizele garantit. - Trop de petits shards : cluster state lourd, mémoire et requêtes gaspillées. Limite par défaut : 1 000 shards par nœud (
cluster.max_shards_per_node). - Nombre de primaires d'un index à fort débit : de l'ordre du nombre de nœuds data hot, pour répartir l'écriture.
2. Mémoire et indexation #
Les réglages qui comptent.
Réglages #
| Réglage | Recommandation |
|---|---|
| Heap JVM | ≤ 50 % de la RAM (le reste sert au cache du système de fichiers, essentiel à Lucene) et sous ~31 Go |
refresh_interval | 30 s ou plus pour les logs (1 s par défaut) : moins de segments, indexation plus rapide |
| Chargement initial | number_of_replicas: 0 et refresh_interval: -1, puis rétablir |
| Bulk | 5 à 15 Mo par requête, plusieurs clients en parallèle, surveiller les rejets |
| Champs | Pas de champ text inutile ; index: false sur les champs jamais recherchés |
| Disques | SSD locaux pour le tier hot |
3. Mesurer #
Capacity planning.
Benchmark #
pip install esrally
esrally race --track=http_logs --target-hosts=es01:9200 --pipeline=benchmark-only \
--client-options="use_ssl:true,verify_certs:false,basic_auth_user:'elastic',basic_auth_password:'$ES_PASSWORD'"- Mesurer le débit d'indexation et la latence de recherche sur un nœud avec vos données (ou une piste Rally proche).
- En déduire le nombre de nœuds hot pour le débit cible, avec une marge de 30 %.
- Calculer le stockage : volume par jour × (1 + répliques) × rétention par tier × facteur d'index (souvent 1,1 à 1,5 par rapport aux données brutes).
- Revalider à chaque changement majeur de version ou de mapping.
Erreur Courante : Ne lancez jamais un benchmark Rally sur un cluster de production : il crée ses propres index et sature le cluster.
