Procédure de tri d'un cluster red/yellow (quel index, quel shard, pourquoi)

Commande

GET _cluster/health?filter_path=status,unassigned_shards,initializing_shards,delayed_unassigned_shards,number_of_pending_tasks
GET _health_report?verbose=false
GET _cat/indices?v&health=red&h=health,index,pri,rep,docs.count,store.size
GET _cat/indices?v&health=yellow&h=health,index,pri,rep
GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,unassigned.for,node&s=state
# Without a body, the call explains the first unassigned shard:
GET _cluster/allocation/explain

Ce que fait la commande

Donne une procédure de tri ordonnée, de l'état du cluster jusqu'aux index en cause, puis aux shards non assignés et à la raison de leur non-allocation (unassigned.reason, allocation explain) ; _health_report résume quel indicateur (disque, disponibilité des shards, master) est en mauvaise santé.

Quand l'utiliser

Comme première réponse quand le cluster passe en red ou yellow.

Attention

Red : au moins un shard primaire n'est pas assigné ; les écritures dans cet index et les recherches touchant ce shard échouent. Yellow : tous les primaires sont présents mais des réplicas manquent ; les données sont accessibles mais sans redondance. Sur un cluster à un seul nœud, les index avec replicas > 0 restent yellow en permanence (décision same_shard). Si un nœud est parti récemment, les delayed_unassigned_shards sont retenus volontairement jusqu'à l'expiration de index.unassigned.node_left.delayed_timeout (1m par défaut).