Чем снимаете статистику по heap size и приходит-ли эта статистика всегда без задержек?
Делаем запрос через NEST на .Net:client.Nodes.StatsAsync()и пишем в базу, потом отображаем в Графане. Да, всегда без задержек.
Можно, конечно, подкрутить cluster.fault_detection.follower_check.timeout до 60s, но мне кажется это не выход. Проблема всегда с одной нодой
Вот во время инцидента из базы статистика. С node-00 пришла без задержек.
Кстати, ещё раз в 10 секунд снимает статистику GitHub - opserver/Opserver: Stack Exchange's Monitoring System
мы тоже пытаемся перейти с 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-ке принципиально новій механизм:
Мне кажется это всё и объясняет: раньше timeout был 30s и даже ваш @andrx первый респонс 12407ms влезал в него. Наши влезали со второй попытки
спасибо, понял. я сейчас поменяю на 30с, дам нагрузку потестирую кластер.
у меня 13 нод по 32GB RAM, heap: 50%. думаешь G1GC подойдет для такого случая.
@Denis_Lamanov после стресс тестов такого warning'a не увидел. спасибо
Аналогичная ситуация после изменения таймаута. Но причина думаю кроется в VM или GC.
Сейчас тестируем G1GC на тестовом кластере
@Denis_Lamanov буду признателен, если поделитесь результатами
Единственная ошибка которая осталась:
[2019-10-20T19:03:03,414][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412594] overhead, spent [278ms] collecting in the last [1s]
[2019-10-20T19:03:04,415][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412595] overhead, spent [383ms] collecting in the last [1s]
[2019-10-20T19:03:09,533][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412596] overhead, spent [285ms] collecting in the last [1s]
[2019-10-20T19:03:10,249][ERROR][o.e.x.m.c.n.NodeStatsCollector] [node-06] collector [node_stats] timed out when collecting data
[2019-10-20T19:03:11,723][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412598] overhead, spent [279ms] collecting in the last [1s]
[2019-10-20T19:03:12,724][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412599] overhead, spent [270ms] collecting in the last [1s]
[2019-10-20T19:03:16,765][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412603] overhead, spent [366ms] collecting in the last [1s]
И как всегда Игорь был прав: статистика часто падает с таймаутом и в этот момент на этой ноде трафик индексации проседает на пару секунд. Всё что извне требует статистику по нодам я отключил: Кибану, наш сервис.
Это такой баг или упёрлись в какой-то ресурс?
Как можно увеличить таймаут?
Надо выяснить почему такие длинные GC. logs/gc.log куда-нибудь выложить можете?
Там нет, к сожалению, того, что я искал. Вы не поищите в прошлых gc.log последнюю строку MaxNewSize и не пришлете ее сюда?
Сделаю. Поищу и на всех нодах
Желательно на том узле, с которого вы прислали последний gc.log. Кстати, на мастере вы видите строки типа:
[2019-10-20T19:03:16,765][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412603] overhead, spent [366ms] collecting in the last [1s]
Если нет - то мне нужна вся эта информация с узлов, на которых это GC появляются в логах.
На этой же ноде(мастере) в gc.log за октябрь нет строк с MaxNewSize. Только в марте
На других нода во всех gc.log тоже нет таких строк
[2019-10-20T19:03:16,765][INFO ][o.e.m.j.JvmGcMonitorService] [node-06] [gc][412603] overhead, spent [366ms] collecting in the last [1s]
Да, на мастере и на остальных нода такие записи постоянны
Логи Эластика за сегодня с мастера и другой ноды
Сейчас мы убрали где-то четверть нагрузки и четверть шард для разгрузки.
Хотим роль мастера повесить на отдельную виртуалку и сделать полный кластера
Этот кластер и раньше прокачивал такой трафик и даже на четверть больше и таких проблем не было на 6.8 и даже на 7.3.2
https://drive.google.com/drive/folders/1Iejb1Oh4jh-BxpBigJflBd-thcgulN-K?usp=sharing
По ссылке появляется пустая папка. Наверное, ничего еще не загрузилось. Давайте тогда GET _nodes и GET _nodes/stats посмотрим. Надо посмотреть, как вы эти узлы настроили. У меня такое впечатление, что вы им больше чем 30 гигов хипа дали.