Основные инструменты и методы отладки проблем кластера Elasticsearch

Проблемы кластера Elasticsearch обычно проявляются как статус здоровья red или yellow, медленные поиски, отклоненные записи или выпадение узлов из кластера. Самый быстрый способ их отладки — начать с состояния здоровья кластера, затем сузить проблему до шардов, узлов, правил распределения, логов или нагрузки на ресурсы.

Это руководство описывает встроенные инструменты, которые вы будете использовать чаще всего: _cat API, _cluster/allocation/explain, статистику узлов, ожидающие задачи и логи Elasticsearch.

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

Состояние здоровья кластера дает первый сигнал:

green: Все первичные и реплицированные шарды распределены.
yellow: Все первичные шарды распределены, но один или несколько реплицированных шардов не распределены.
red: Один или несколько первичных шардов не назначены, поэтому некоторые данные недоступны.

Кластер со статусом yellow все еще может обслуживать чтение и запись для доступных первичных шардов, но имеет меньшую избыточность. Кластер со статусом red требует немедленного расследования, так как затронутые первичные шарды недоступны.

Начните с `_cat` API

_cat API созданы для быстрых проверок в удобном для чтения формате.

curl -X GET "localhost:9200/_cat/health?v"
curl -X GET "localhost:9200/_cat/nodes?v&h=name,ip,heap.percent,ram.percent,cpu,disk.used_percent,load_1m,node.role"
curl -X GET "localhost:9200/_cat/shards?v"
curl -X GET "localhost:9200/_cat/indices?v"

Используйте _cat/health для подтверждения общего состояния. Используйте _cat/shards для поиска UNASSIGNED, INITIALIZING или постоянно перемещающихся шардов. Используйте _cat/nodes для выявления нагрузки на кучу, CPU или диск на конкретном узле.

Для кластера со статусом red или yellow эта команда дает сфокусированное представление:

curl -X GET "localhost:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index"

Объяснение распределения шардов

Когда шард не назначен, _cluster/allocation/explain сообщает, почему Elasticsearch не может его разместить.

curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" \
  -H 'Content-Type: application/json' -d'
{
  "index": "my_index",
  "shard": 0,
  "primary": true
}'

Вы также можете попросить Elasticsearch объяснить первый неназначенный шард, который он найдет:

curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" \
  -H 'Content-Type: application/json' -d'{}'

Прочитайте поля can_allocate, allocate_explanation и node_allocation_decisions. Распространенные причины включают водяные знаки диска, фильтрацию распределения, отсутствующие узлы, несовместимые настройки индекса или слишком мало узлов данных для запрошенного количества реплик.

Проверьте статистику узлов и кластера

Когда здоровье зеленое, но поиск или запись медленные, проверьте нагрузку на ресурсы.

curl -X GET "localhost:9200/_nodes/stats/jvm,fs,os,process,thread_pool?pretty"
curl -X GET "localhost:9200/_cluster/stats?pretty"

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

Для отклонений в пуле потоков используйте:

curl -X GET "localhost:9200/_cat/thread_pool/search,write?v&h=node_name,name,active,queue,rejected,completed"

Отклоненные задачи обычно означают, что узел не справляется с частотой запросов. Устраните причину перед увеличением очередей: уменьшите стоимость запроса, распределите шарды, масштабируйте узлы или замедлите массовую индексацию.

Просмотр ожидающих задач и восстановления

Если изменения состояния кластера кажутся застрявшими, проверьте ожидающие задачи:

curl -X GET "localhost:9200/_cluster/pending_tasks?pretty"

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

Для перемещения и восстановления шардов используйте:

curl -X GET "localhost:9200/_cat/recovery?v&active_only=true"

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

Чтение логов Elasticsearch

Логи Elasticsearch часто объясняют то, на что API только намекают. Проверяйте логи на затронутом узле, а не на случайном узле в кластере.

Ищите сообщения, такие как:

master not discovered
flood-stage disk watermark
circuit_breaking_exception
rejected execution
failed to obtain node locks
shard failed

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

curl -X PUT "localhost:9200/*/_settings?expand_wildcards=all" \
  -H 'Content-Type: application/json' -d'
{
  "index.blocks.read_only_allow_delete": null
}'

Практический поток отладки

Используйте этот порядок, если не знаете, с чего начать:

Проверьте _cat/health?v, чтобы увидеть, является ли проблема обще кластерной.
Используйте _cat/shards?v для поиска неназначенных, перемещающихся или горячих шардов.
Запустите _cluster/allocation/explain для неназначенных шардов.
Проверьте _cat/nodes на предмет кучи, CPU, диска и ролей узлов.
Просмотрите логи узлов на предмет сообщений о распределении, диске, JVM и автоматическом выключателе.
Используйте статистику узлов и пула потоков, если проблема в задержке или отклоненных запросах.

Ключевой вывод

Отладка Elasticsearch работает лучше всего, когда вы переходите от широких проверок здоровья к точному шарду, узлу или настройке, вызывающей проблему. Начните с _cat/health, _cat/shards и allocation explain, затем используйте логи и статистику узлов для подтверждения коренной причины перед изменением настроек.