› ›

Отладка обнаружения

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

Если в вашем кластере нет стабильного мастера, многие его функции будут работать неправильно, и Elasticsearch будет сообщать об ошибках клиентам и в своих логах. Вам необходимо устранить нестабильность мастер-узла перед устранением других проблем. Невозможно решить другие проблемы, пока нет избранного мастера или выбранный мастер-узел нестабилен.

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

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

В следующих разделах описаны некоторые распространенные проблемы с обнаружением и избранием мастера.

Мастер не избран

Когда узел побеждает в выборах мастера, он регистрирует сообщение, содержащее elected-as-master, и все узлы регистрируют сообщение, содержащее master node changed, определяющее новый избранный мастер-узел.

Если нет избранного мастера и ни один узел не может выиграть выборы, все узлы будут повторять запись сообщений о проблеме, используя логгер под названием org.elasticsearch.cluster.coordination.ClusterFormationFailureHelper. По умолчанию это происходит каждые 10 секунд.

Выборы мастера затрагивают только узлы, имеющие право на роль мастера, поэтому сосредоточьтесь на узлах, имеющих право быть мастером в этой ситуации. Логи этих узлов укажут требования для выборов мастера, такие как обнаружение определенного набора узлов. API состояния на этих узлах также предоставит полезную информацию о ситуации.

Если логи или отчет о состоянии указывают, что Elasticsearch не может обнаружить достаточно узлов для формирования кворума, необходимо устранить причины, препятствующие Elasticsearch в обнаружении отсутствующих узлов. Отсутствующие узлы необходимы для восстановления метаданных кластера. Без метаданных кластера данные в вашем кластере бессмысленны. Метаданные кластера хранятся на подмножестве узлов, имеющих право на роль мастера в кластере. Если кворум не может быть обнаружен, то отсутствующие узлы были теми, кто хранил метаданные кластера.

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

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

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

Паузы GC записываются в логах GC, которые Elasticsearch генерирует по умолчанию, а также обычно в логах главного узла JvmMonitorService. Используйте эти логи, чтобы подтвердить, испытывает ли узел высокую загрузку кучи с длительными паузами GC. Если это так, руководство по устранению неполадок с высокой загрузкой кучи содержит некоторые предложения для дальнейшего расследования, но, как правило, вам потребуется захватить дамп кучи и логи сборщика мусора во время высокой загрузки кучи, чтобы полностью понять проблему.
Паузы виртуальной машины также влияют на другие процессы на том же хосте. Пауза виртуальной машины обычно приводит к разрыву системного времени, что Elasticsearch сообщит в своих логах. Если вы обнаружите доказательства приостановки других процессов в то же время или неожиданных разрывов времени, исследуйте инфраструктуру, на которой вы работаете с Elasticsearch.
Снимки пакетов покажут системные и сетевые сбои, особенно если вы одновременно захватываете сетевой трафик на всех соответствующих узлах и анализируете его вместе с логами Elasticsearch с этих узлов. Вы должны увидеть любые повторные передачи, потерю пакетов или другие задержки в соединениях между узлами.
Длительные ожидания, чтобы определенные потоки были доступны, могут быть определены путем получения дампов стека основного процесса Elasticsearch (например, с помощью jstack) или профилирования трассировки (например, с помощью Java Flight Recorder) в несколько секунд, предшествующих соответствующему сообщению в журнале.

API горячих потоков узлов иногда предоставляет полезную информацию, но помните, что этому API также необходимо множество transport_worker и generic потоков на всех узлах кластера. API может быть затронут той самой проблемой, которую вы пытаетесь диагностировать. jstack намного надежнее, поскольку не требует никаких потоков JVM.

Потоки, участвующие в обнаружении и членстве в кластере, в основном являются transport_worker и cluster_coordination потоками, для которых не должно быть длительного ожидания. Также могут быть доказательства длительных ожиданий потоков в логах Elasticsearch, особенно в логах предупреждений из org.elasticsearch.transport.InboundHandler. См. Модель потоков сетевого взаимодействия для получения дополнительной информации.

Мастер избран, но нестабилен

Когда узел побеждает в выборах мастера, он регистрирует сообщение, содержащее elected-as-master. Если это происходит неоднократно, избранный мастер-узел нестабилен. В этой ситуации сосредоточьтесь на логах узлов, имеющих право быть мастером, чтобы понять, почему узел-победитель перестает быть мастером и запускает новые выборы. Если логи указывают на нестабильность мастера из-за таймаутов или сетевых проблем, уточните проблему следующим образом.

Паузы GC записываются в логах GC, которые Elasticsearch генерирует по умолчанию, а также обычно в логах главного узла JvmMonitorService. Используйте эти логи, чтобы подтвердить, испытывает ли узел высокую загрузку кучи с длительными паузами GC. Если это так, руководство по устранению неполадок с высокой загрузкой кучи содержит некоторые предложения для дальнейшего расследования, но, как правило, вам потребуется захватить дамп кучи и логи сборщика мусора во время высокой загрузки кучи, чтобы полностью понять проблему.
Паузы виртуальной машины также влияют на другие процессы на том же хосте. Пауза виртуальной машины обычно приводит к разрыву системного времени, что Elasticsearch сообщит в своих логах. Если вы обнаружите доказательства приостановки других процессов в то же время или неожиданных разрывов времени, исследуйте инфраструктуру, на которой вы работаете с Elasticsearch.
Снимки пакетов покажут системные и сетевые сбои, особенно если вы одновременно захватываете сетевой трафик на всех соответствующих узлах и анализируете его вместе с логами Elasticsearch с этих узлов. Вы должны увидеть любые повторные передачи, потерю пакетов или другие задержки в соединениях между узлами.
Длительные ожидания, чтобы определенные потоки были доступны, могут быть определены путем получения дампов стека основного процесса Elasticsearch (например, с помощью jstack) или профилирования трассировки (например, с помощью Java Flight Recorder) в несколько секунд, предшествующих соответствующему сообщению в журнале.

API горячих потоков узлов иногда предоставляет полезную информацию, но помните, что этому API также необходимо множество transport_worker и generic потоков на всех узлах кластера. API может быть затронут той самой проблемой, которую вы пытаетесь диагностировать. jstack намного надежнее, поскольку не требует никаких потоков JVM.

Потоки, участвующие в обнаружении и членстве в кластере, в основном являются transport_worker и cluster_coordination потоками, для которых не должно быть длительного ожидания. Также могут быть доказательства длительных ожиданий потоков в логах Elasticsearch, особенно в логах предупреждений из org.elasticsearch.transport.InboundHandler. См. Модель потоков сетевого взаимодействия для получения дополнительной информации.

Узел не может обнаружить или присоединиться к стабильному мастеру

Если есть стабильный избранный мастер, но узел не может обнаружить его или присоединиться к кластеру, он будет повторять запись сообщений о проблеме, используя логгер ClusterFormationFailureHelper. API состояния на затронутом узле также предоставит полезную информацию о ситуации. Другие сообщения в логах на затронутом узле и избранном мастере могут предоставить дополнительную информацию о проблеме. Если логи показывают, что узел не может обнаружить или присоединиться к кластеру из-за таймаутов или сетевых проблем, уточните проблему следующим образом.

Паузы GC записываются в журналы GC, которые Elasticsearch генерирует по умолчанию, а также обычно и в журналы основных узлов. Используйте эти журналы, чтобы подтвердить, испытывает ли узел высокую загрузку кучи с длительными паузами GC. Если это так, руководство по устранению неполадок с высокой загрузкой кучи содержит некоторые предложения для дальнейшего исследования, но обычно вам нужно будет захватить дамп кучи и журналы сборщика мусора во время периода высокой загрузки кучи, чтобы полностью понять проблему.
Паузы VM также влияют на другие процессы на том же хосте. Пауза VM обычно также вызывает разрыв в системных часах, о чем Elasticsearch сообщит в своих журналах. Если вы видите доказательства приостановки работы других процессов в то же время или неожиданные разрывы в часах, исследуйте инфраструктуру, на которой вы работаете с Elasticsearch.
Перехваты пакетов выявят проблемы на системном и сетевом уровнях, особенно если вы перехватываете сетевой трафик одновременно на всех соответствующих узлах и анализируете его вместе с журналами Elasticsearch с этих узлов. Вы должны иметь возможность наблюдать повторные передачи, потерю пакетов или другие задержки в соединениях между узлами.
Длительные ожидания для доступности определенных потоков можно выявить, взяв дампы стека основного процесса Elasticsearch (например, используя jstack) или трассировку профилирования (например, используя Java Flight Recorder) в течение нескольких секунд, предшествующих соответствующему сообщению в журнале.

API горячих потоков узлов иногда дает полезную информацию, но помните, что этому API также требуется определенное количество transport_worker и generic потоков на всех узлах кластера. API может быть затронут той самой проблемой, которую вы пытаетесь диагностировать. jstack гораздо надежнее, так как не требует каких-либо потоков JVM.

Потоки, участвующие в обнаружении и членстве в кластере, в основном transport_worker и cluster_coordination потоки, для которых длительного ожидания быть не должно. Также могут быть доказательства длительного ожидания потоков в журналах Elasticsearch, особенно при рассмотрении предупреждающих сообщений из org.elasticsearch.transport.InboundHandler. Дополнительную информацию см. в разделе модель потоков сети.

Присоединение узла к кластеру и повторное его отсоединение

Если узел присоединяется к кластеру, но Elasticsearch определяет его как неисправный, он будет удален из кластера. Дополнительную информацию см. в разделе устранения неполадок нестабильного кластера.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/8.17/discovery-troubleshooting.html