Порядок разбора красного/жёлтого кластера (какой индекс, какой шард, почему)

Команда

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

Что делает

Задаёт упорядоченный порядок разбора: от состояния кластера к проблемным индексам, затем к неназначенным шардам и причине, по которой они не распределены (unassigned.reason, allocation explain); _health_report кратко показывает, какой индикатор (диск, доступность шардов, master) не в порядке.

Когда использовать

Как первое действие, когда кластер становится красным или жёлтым.

Внимание

Red: хотя бы один первичный шард не назначен; запись в этот индекс и поиски, затрагивающие этот шард, завершаются ошибкой. Yellow: все первичные на месте, но реплик не хватает; данные доступны, но избыточности нет. В кластере из одного узла индексы с replicas > 0 постоянно остаются жёлтыми (решение same_shard). Если узел недавно ушёл, delayed_unassigned_shards намеренно удерживаются до истечения index.unassigned.node_left.delayed_timeout (по умолчанию 1m).