7.3.2 и потеря мастера

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

Так, похоже проблема найдена: во всех случаях удаления ноды от мастера была причина: reason: ApplyCommitRequest
Насколько я понял по форуму это повреждённый индекс или transaction log.
После установки 7.3 я увидел старые индексы за март, которые 6.8 не показывал.
Удалив их всё нормализовалось и ноды перестали отлетать. Объясняет ли это проблему в GC?

Вы, скорее всего, прочитали про flush, он же Lucene commit. ApplyCommitRequest - это часть процесса публикации состояния кластера на все ноды. В результате длинных пауз в результате блокировки во время сборки мусора, ноды не подтверждали во время новое состояние кластера, что и вызывало сбои.

Индексы, которые появились - это так называемые dangling indices. Они могли вызывать дополнительную нагрузку на кластер. Если у вас сообщения про GC после этого исчезли - то все нормально, если они все еще появляются - то ваше спокойствие временное и проблемы вернутся как только вы увеличите нагрузку на кластер.

Всё нормализовалось. Больше такого не наблюдали

Обновились на 7.4. В плане производительности стало лучше. Но мастер всё таки раз в 2-3 дня отваливается. При этом никакой резкой нагрузки, всплеска или видимых причин не видно.

Вот что в этот момент в логах дата нод которые с ролью мастера, но не были в этот момент мастером:

В этот момент в логах избранного мастера:

Что можете посоветовать? На версиях до 7-ки такого не было

Судя по логам т.к. у нас не SSD диски, то обновление мета-информации о каждоом индексе(которых у нас больше чем 1000 на ноду) на диске иногда превышает cluster.publish.timeout (Rolling upgrade problem from 6.8 to 7.1.1)
Собственно этот механизм, судя по документации, ввели в 7-ке
https://www.elastic.co/guide/en/elasticsearch/reference/7.4/cluster-state-publishing.html

У вас ноду залипают не только на state publishing, но и не очень легких запросов вроде internal:coordination/fault_detection/follower_check. Другими словами, некоторые ноды перестают отвечать на любые запросы по 15-40 секунд. Отсюда и все проблемы. Почему это происходит, я сказать затрудняюсь. Может VM глючит, может сеть. Когда такие проблемы происходит, вы можете попробовать на машину залогиниться и посмотреть - а машина то сама отзывается, или все остальное тоже тормозит.

Да, логинился в это время на проблемную ноду - ничего не тормозит. Всё в нормальном режиме: сеть не пропадала, диск и процессор не нагружены

Пока что подкрутил так:

cluster.join.timeout: 180s
cluster.publish.timeout: 180s
cluster.follower_lag.timeout: 180s

Но ещё заметил, что бывает часто когда нода отваливается от мастера и в вечном цикле подключается и сразу же отключается пока не перезагрузишь её

Действительно, одна нода отваливается по internal:coordination/fault_detection/follower_check

Какие можно включить trace в логировании чтобы посмотреть более детально?
Параллельно смотрим на железо, но предварительно там всё хорошо и сеть не пропадает в это время

У Вас для этого кластера мониторинг настроен?

Мониторинг через Zabbix и ещё снимаем раз в минуту статистику по Heap Size и Open descriptors

Интересно, что после того как мастер отключил ноду по таймауту, то чуть позже приходят запоздалые ответы на респонсы (лог с мастера):

[2019-10-15T06:40:51,152][INFO ][o.e.c.s.MasterService ] [node-01] node-left[{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true} followers check retry count exceeded], term: 24, version: 110637, reason: removed {{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true},} [2019-10-15T06:40:53,929][WARN ][o.e.t.TransportService ] [node-01] Received response for a request that has timed out, sent [38172ms] ago, timed out [28069ms] ago, action [internal:coordination/fault_detection/follower_check], node [{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true}], id [8400909] [2019-10-15T06:40:53,997][WARN ][o.e.t.TransportService ] [node-01] Received response for a request that has timed out, sent [27268ms] ago, timed out [17312ms] ago, action [internal:coordination/fault_detection/follower_check], node [{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true}], id [8403538] [2019-10-15T06:40:54,000][WARN ][o.e.t.TransportService ] [node-01] Received response for a request that has timed out, sent [16311ms] ago, timed out [6340ms] ago, action [internal:coordination/fault_detection/follower_check], node [{node-00}{A9AdXLb5QA-ZMcicCn26OQ}{zkM7E5SdSmG6MdvxLMPiRQ}{10.1.3.110}{10.1.3.110:9300}{dilm}{ml.machine_memory=134928560128, ml.max_open_jobs=20, xpack.installed=true}], id [8405154]

Вот история Heap Size по нодам(инцидент произошел в 6:40)

Чем снимаете статистику по heap size и приходит-ли эта статистика всегда без задержек?

Делаем запрос через NEST на .Net:client.Nodes.StatsAsync()и пишем в базу, потом отображаем в Графане. Да, всегда без задержек.
Можно, конечно, подкрутить cluster.fault_detection.follower_check.timeout до 60s, но мне кажется это не выход. Проблема всегда с одной нодой

Вот во время инцидента из базы статистика. С node-00 пришла без задержек.

Кстати, ещё раз в 10 секунд снимает статистику https://github.com/opserver/Opserver

мы тоже пытаемся перейти с ES6.8.2 на ES7.4. В моем случае данные не мигрировали, а заново были загружены. все вроде хорошо, ноды не уходят как у вас, но иногда такие же warnings, когда пытаемся грузить:

 [WARN ][o.e.t.TransportService   ] [master-1] Received response for a request that has timed out, sent [12407ms] ago, timed out [2401ms] ago,
action [internal:coordination/fault_detection/follower_check], node [{data-1}{2kpk52EcT-KFIU7oH6CkRA}{6gLIJNVARFS8Y-5ec3jYGA}{10.15.1.227}{10.15.1.227:9300}{di}{xpack.installed=true, role=data}], id [2069258]

я не совсем понимаю, чем это может быть обусловлено и как можно проверить?

проверяем статус кластера через datadog - там никаких отклонений от норм.

Есть 3 попытки на follower_check. У вас response вовремя приходит на 2 или 3. Поэтому нода и не отпадает.

Но да, это плохо. То, что без проблем работало и с большей нагрузкой в 6-ке плохо работает в 7-ке

А поможет ли переход на G1GC? У него ведь на порядок меньше задержки

a, вот нашел здесь. спасибо, @Denis_Lamanov , непонятно тогда почему это появилось, потому что настройки связанные с конфигурацией сети не меняли.

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

Мне интересно, чему этот параметр равен в ES6.8? в документации к шестой версии ничего не сказано. Если это новая фича семерки, то какой аналог или как себя вела шестая версия?

В 6-ой версии тоже были настройки
https://www.elastic.co/guide/en/elasticsearch/reference/6.8/modules-discovery-zen.html
Там ping_timeout был 30s
В 7-ке принципиально новій механизм: