AK
Мне кажется, это как состояние доступности узла кластера определять тем, работает ли на нём приложение.
Size: a a a
2019 November 20
ДУ
Мне кажется, это как состояние доступности узла кластера определять тем, работает ли на нём приложение.
На узел ты можешь сходить
AK
На узел ты можешь сходить
Там просто постоянный хартбит идёт между узлами, чтобы опрелделить доступность партнёра
ДУ
Чем не хватает agent.ping nodata()?
ДУ
Там просто постоянный хартбит идёт между узлами, чтобы опрелделить доступность партнёра
Тогда надо вводить хартбит в активный агент.
AK
Чем не хватает agent.ping nodata()?
Дело не в том, что чего-то не хватает же. =)
ДУ
Именно хартбит, а не какой то ключ
AK
Тогда надо вводить хартбит в активный агент.
Вот, я выше это тоже написал. Но тут всплывало то, что люди отказываются от agent.ping ради снижения нагрузки, а тут целый хартбит еще.
ДУ
Вот, я выше это тоже написал. Но тут всплывало то, что люди отказываются от agent.ping ради снижения нагрузки, а тут целый хартбит еще.
Вот это прям дичь дикая
ДУ
Отказаться от одной проверки, а данные от агента по всем проверять
AK
Отказаться от одной проверки, а данные от агента по всем проверять
Я может быть наврал в причине отказа, но что-то вроде того. =) А agent.ping же у нас только пассивная. да?
ДУ
Нет, активная тоже есть
AK
С этой проверкой для активных проверок по сути более сложная логика, чем для пассивных должна быть. Нужно смотреть должны ли быть получены данные в соответствии с расписанием проверки +- некий таймаут.
AK
Плюс нужно учитывать какие метрики уже были отправлены агенту на проверку.
ДУ
Именно. Поэтому правильнее прокси и пассивные проверки
AK
Плюс нужно учитывать какие активны метрики прокси сервер забрал.
AK
Много мороки ради зелёного индикатора. И более простые
AK
вещи ещё не сделаны.
AK
Тут тогда ещё нужно, чтобы прокси и агенты постоянные сессии держали. Иначе пропихнуть обновления проверок нельзя. Постоянные сессии тут скорее зло...
AK
По идее они вообще могли в части случаев udp использовать