Устранение красного статуса кластера: пошаговое руководство по устранению неполадок Elasticsearch

Красный статус кластера Elasticsearch означает, что по крайней мере один первичный шард не выделен. Это то, что имеет значение. Некоторые данные могут быть недоступны, поиск по затронутым индексам может возвращать частичные или неудачные результаты, а запись в эти шарды не может выполняться нормально.

Желтый статус отличается: первичные шарды выделены, но одна или несколько реплик — нет. Желтый статус все еще заслуживает внимания, так как у вас меньше избыточности, но красный — это инцидент. Не начинайте с удаления данных или перенаправления шардов вручную. Сначала найдите, какой первичный шард не назначен и почему Elasticsearch отказывается его выделять.

Понимание здоровья кластера Elasticsearch

Elasticsearch предоставляет API здоровья кластера, который дает снимок состояния кластера и распределения шардов. Этот API является вашим основным инструментом для диагностики проблем со здоровьем.

GET _cluster/health

Вывод этой команды будет включать поле status, которое может быть green, yellow или red. Он также предоставляет информацию о количестве активных и неназначенных шардов.

• Green: Все первичные и реплицированные шарды выделены и работают корректно.
• Yellow: Все первичные шарды выделены, но некоторые реплицированные шарды не назначены.
• Red: Один или несколько первичных шардов не назначены, что приводит к недоступности данных для этих шардов.

Используйте более детальный вызов здоровья, когда вы находитесь в инциденте:

GET _cluster/health?level=indices

Затем перечислите неназначенные шарды:

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index

Распространенные причины и шаги по устранению красного/желтого статуса

Когда ваш кластер не green, пришло время расследования. Вот наиболее распространенные причины неназначенных шардов и способы их решения:

1. Недостаточно дискового пространства

Elasticsearch имеет защитные механизмы для предотвращения повреждения данных из-за полных дисков. Если на узле заканчивается дисковое пространство, он предотвращает выделение новых шардов или восстановление существующих.

Диагностика:

• Проверьте использование диска на каждом узле.
• Используйте API объяснения выделения кластера, чтобы понять, почему шарды не назначены.

GET _cluster/allocation/explain

Этот API предоставит подробное объяснение, часто указывающее на дисковые водяные знаки.

Решение:

• Освободите дисковое пространство: Удалите старые индексы, переместите данные на другой уровень или добавьте емкость. Принудительное слияние активных индексов не является быстрым способом освобождения дискового пространства и может добавить большую нагрузку ввода-вывода во время инцидента.
• Добавьте больше дискового пространства: Увеличьте емкость хранилища ваших узлов.
• Настройте дисковые водяные знаки: Изменяйте cluster.routing.allocation.disk.watermark.low, high и flood_stage только тогда, когда текущие значения неверны для вашей среды. Повышение водяных знаков может выиграть время, но также может скрыть реальную проблему с емкостью.

2. Узел покинул кластер (вытеснение узла)

Узлы могут покидать кластер из-за сетевых проблем, сбоев или намеренного удаления. Если узел, содержащий шарды (особенно первичные шарды), покидает кластер, эти шарды становятся неназначенными.

Диагностика:

• Проверьте журналы кластера на предмет узлов, которые недавно покинули кластер.
• Мониторьте сетевое соединение между узлами.
• Убедитесь, что все узлы могут обнаруживать друг друга. Проверьте discovery.seed_hosts, транспортное соединение и журналы кластера. Не вводите cluster.initial_master_nodes повторно в уже сформированный кластер в качестве общего исправления.

Решение:

• Перезапустите узел: Если узел вышел из строя или перестал отвечать, попробуйте перезапустить его.
• Решите сетевые проблемы: Устраните любые проблемы сетевого соединения между узлами.
• Повторно добавьте узел: Если узел был намеренно удален, убедитесь, что он правильно настроен перед повторным присоединением к кластеру.

3. Фильтрация и осведомленность о выделении шардов

Неправильно настроенные правила выделения шардов могут препятствовать назначению шардов на доступные узлы.

Диагностика:

• Просмотрите ваши настройки cluster.routing.allocation.*, особенно фильтры cluster.routing.allocation.include, exclude и require.
• Проверьте cluster.routing.allocation.awareness.attributes, если вы используете осведомленность о зонах или стойках.

Решение:

• Настройте фильтры выделения: Измените фильтры, чтобы разрешить выделение шардов на соответствующие узлы.
• Исправьте атрибуты осведомленности: Убедитесь, что узлы правильно помечены атрибутами осведомленности, если они используются, и что ваши правила выделения их учитывают.

4. Недостаточно дискового пространства для выделения (после создания индекса)

Даже если диск не заполнен, Elasticsearch может предотвратить выделение шардов, если он прогнозирует, что диск превысит высокие водяные знаки после выделения. Это связано с дисковыми водяными знаками, но особенно влияет на новые выделения.

Диагностика:

• API _cluster/allocation/explain здесь бесценен.
• Проверьте свободное пространство по сравнению с ожидаемым размером шардов.

Решение:

• Аналогично общей проблеме с дисковым пространством: освободите место, добавьте больше хранилища или осторожно настройте водяные знаки.

5. Размер шарда и емкость узла

Очень большие шарды или большое количество шардов могут нагружать ресурсы узла (ЦП, память) и влиять на выделение. Кроме того, если узел достиг своего лимита шардов (cluster.routing.allocation.total_shards_per_node), новые шарды не будут ему выделяться.

Диагностика:

• Проверьте размеры шардов (GET _cat/shards?v).
• Мониторьте использование ресурсов узла (ЦП, память).
• Просмотрите настройку cluster.routing.allocation.total_shards_per_node.

Решение:

• Уменьшите нагрузку шардов: Для будущих индексов настройте переключение и количество шардов так, чтобы шарды попадали в управляемый диапазон размеров. Для существующих индексов используйте переиндексацию, сжатие или разделение только после того, как кластер станет достаточно стабильным, чтобы справиться с работой.
• Увеличьте емкость узла: Добавьте более мощные узлы или узлы с большим объемом памяти/ЦП.
• Настройте лимит шардов: При необходимости и наличии достаточных ресурсов увеличьте cluster.routing.allocation.total_shards_per_node.

6. Проблемы с мастер-узлом

Нестабильный мастер-узел может привести к проблемам с выделением шардов. Если мастер недоступен или не может выполнять свои обязанности, шарды могут стать неназначенными.

Диагностика:

• Проверьте журналы кластера на наличие ошибок или предупреждений, связанных с мастером.
• Убедитесь, что у вас нечетное количество узлов, имеющих право быть мастером (обычно 3 или 5), чтобы избежать сценариев разделения мозга.
• Проверьте, что узлы, имеющие право быть мастером, могут выбрать мастера.

Решение:

• Стабилизируйте мастер: Убедитесь, что узлы, имеющие право быть мастером, здоровы, имеют достаточные ресурсы и хорошо связаны.
• Проверьте историю начальной загрузки: cluster.initial_master_nodes предназначен только для первого формирования кластера. После начальной загрузки удалите его из конфигураций узлов и устраняйте нестабильность мастера через журналы, транспортную сеть и конфигурацию голосования.

Продвинутая диагностика с помощью _cluster/allocation/explain

API _cluster/allocation/explain — ваш самый мощный инструмент для понимания того, почему конкретный шард не назначен.

Пример:

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Это вернет подробный JSON-вывод, объясняющий, почему первичный шард 0 индекса my-index не может быть выделен. Ищите поля, такие как deciders, которые перечисляют причины неназначения (например, DISK_THRESHOLD, NODE_LEFT, NO_VALID_SHARD_COPY).

Устранение желтого статуса кластера

Желтый статус означает, что первичные шарды выделены, а реплики — нет. Это в первую очередь влияет на избыточность данных и отказоустойчивость.

Распространенные причины:

• Недостаточно узлов: У вас недостаточно узлов для размещения необходимого количества реплик для ваших индексов.
• Фильтрация выделения шардов: Аналогично красному статусу, фильтры могут препятствовать выделению реплик.
• Ограничения дискового пространства: На узлах может быть достаточно места для первичных шардов, но недостаточно для реплик, особенно если активны дисковые водяные знаки.

Решение:

• Добавьте больше узлов: Увеличьте количество узлов в вашем кластере.
• Настройте количество реплик: Уменьшите количество реплик на индекс (index.number_of_replicas), если отказоустойчивость не критична для всех индексов.
• Проверьте настройки выделения: Убедитесь, что реплицированным шардам разрешено выделяться на доступные узлы.

Лучшие практики для поддержания здоровья кластера

• Мониторьте использование диска: Проактивно отслеживайте дисковое пространство на всех узлах и настройте оповещения.
• Правильно подбирайте размер кластера: Убедитесь, что у вас достаточно узлов и ресурсов для вашего объема данных и нагрузки запросов.
• Управление шардами: Поддерживайте размеры шардов в рекомендуемых диапазонах и избегайте избыточного шардирования.
• Регулярно проверяйте здоровье кластера: Используйте GET _cluster/health и GET _cluster/allocation/explain как часть вашего рутинного мониторинга.
• Тестируйте изменения: Перед внесением значительных изменений в настройки выделения или дисковые водяные знаки протестируйте их в тестовой среде.

Как только вы узнаете решающий фактор выделения, путь обычно ясен. Дисковый порог означает емкость. NODE_LEFT означает восстановление или замену отсутствующего узла. NO_VALID_SHARD_COPY означает, что вам может понадобиться восстановление из снимка или осознанное решение о потере данных с использованием документированных процедур небезопасного восстановления Elasticsearch. Последний случай следует обрабатывать медленно, сначала проверив резервные копии, потому что команда, которая выводит кластер из красного статуса, также может подтвердить постоянную потерю последних данных отсутствующего первичного шарда.