1. La méthode #
Toujours dans le même ordre.
Étapes #
GET _cluster/health?filter_path=status,number_of_nodes,unassigned_shards
GET _cat/nodes?v&h=name,node.role,heap.percent,ram.percent,cpu,load_1m,disk.used_percent
GET _cat/shards?v&s=state&h=index,shard,prirep,state,unassigned.reason
GET _cluster/allocation/explain
GET _cat/thread_pool/search,write?v&h=node_name,name,active,queue,rejected
GET _nodes/hot_threads2. Causes fréquentes #
Les classiques.
Tableau #
| Symptôme | Cause | Correction |
|---|---|---|
| Yellow après redémarrage | Répliques en cours de reconstruction ou impossibles (un seul nœud) | Attendre, ajouter un nœud, ou réduire number_of_replicas |
| Red, shards non assignés | Nœud perdu sans réplique, disque plein | allocation/explain, restaurer depuis snapshot |
| Index en lecture seule | Disque au-dessus du seuil flood-stage (95 %) | Libérer de l'espace ; le blocage se lève automatiquement |
| Rejets d'écriture (429) | File du thread pool write saturée | Réduire la concurrence des clients, plus de nœuds, bulk plus gros |
| Circuit breaker | Requête ou agrégation trop gourmande en mémoire | Limiter la taille des agrégations, revoir les champs text agrégés |
| Longues pauses GC | Heap trop petite ou trop grande | Heap ≤ 50 % de la RAM et sous ~31 Go |
3. Slow logs et supervision #
Garder la trace.
Configuration #
PUT logs-nginx-*/_settings
{ "index.search.slowlog.threshold.query.warn": "2s",
"index.search.slowlog.threshold.query.info": "500ms",
"index.indexing.slowlog.threshold.index.warn": "5s" }- Stack Monitoring (via Elastic Agent ou Metricbeat) envoie les métriques du cluster vers un cluster de supervision séparé.
- L'outil support diagnostics d'Elastic collecte toutes les API utiles en une archive pour une analyse ou un ticket de support.
Bonne Pratique : Supervisez le cluster depuis un autre cluster : un cluster en panne ne peut pas montrer ses propres métriques.
