Шквал оповещений после кратковременной потери контакта с прокси нодой

Started by Stanislav, October 11, 2025, 06:52:29 PM

Previous topic - Next topic

Alex Kirhenshtein

Да, SYS_NODE_UNREACHABLE в правило 31 нужно вернуть. Моё замечание от 23.07 было неверным: у нод, подключённых через тоннель, приходит именно SYS_NODE_UNREACHABLE, а не SYS_NODE_DOWN. После того как вы убрали это событие из правила 31, срабатывать ему стало не на чем.

Выбор события определяет не тоннель сам по себе, а наличие у ноды primary IP address:

  • Нода без primary IP (связь только через тоннель агента). Проверка «весь узел недоступен» для неё при отвалившемся агенте не выполняется вообще. Вместо этого сервер отдельно смотрит, остался ли тоннель, и если тоннеля нет — публикует SYS_NODE_UNREACHABLE с параметром reason = "Agent tunnel disconnected". SYS_NODE_DOWN для такой ноды не возникает никогда.
  • Нода с primary IP — обычная логика: SYS_NODE_DOWN, если причина в самой ноде, и SYS_NODE_UNREACHABLE с reason "Router down" / "Switch down" / "Proxy node down", если сервер нашёл причину выше по пути.

Восстановление в обоих случаях — SYS_NODE_UP. Отсюда и картина: up-уведомления приходили, down — нет.

В ваших логах это видно напрямую:

  • ТРК сервер офис, 26.07: 17:25:05 SYS_AGENT_UNREACHABLE, 17:25:49 SYS_TUNNEL_CLOSED, 17:26:37 SYS_NODE_UNREACHABLE, 18:27:15 SYS_NODE_UP. SYS_NODE_DOWN нет ни одного.
  • Смарт сервер 1С, 27.07 03:31:58 — ровно то же самое, и 25.07 09:39:34 тоже. Так что ночное одинокое «Node up» — не отдельная аномалия, а тот же самый случай.

Что сделать: добавить SYS_NODE_UNREACHABLE в правило 31, рядом с SYS_NODE_DOWN. Больше ничего менять не нужно. Флаг "Accept correlated events" и скрипт с maintenance на правиле 31 по-прежнему не нужны: SYS_NODE_UNREACHABLE с reason "Agent tunnel disconnected" не коррелируется (у этих событий в вашем логе Root ID = 0), а в режиме обслуживания события станут коррелированными и правило пропустит их само.

Перечислять оба события в правилах «нода недоступна» стоит всегда — стандартное правило Start downtime устроено именно так, в нём указаны и SYS_NODE_DOWN, и SYS_NODE_UNREACHABLE. Документация тоже говорит, что генерируется одно из двух, в зависимости от причины: https://netxms.org/documentation/adminguide/topology.html

Проверить, какая ветка сработала у вас: откройте SYS_NODE_UNREACHABLE в event log и посмотрите параметр reason. "Agent tunnel disconnected" — нода без primary IP, событие некоррелированное. Любой другой reason означает, что сервер нашёл причину выше по пути; из них коррелируются "Router down", "Switch down", "Proxy node down" и "Proxy agent unreachable" — эти правило 31 без флага пропустит.

Note: асимметрия между правилами 31 и 32 из-за этого остаётся. У 32 флаг включён, у 31 — нет, поэтому коррелированное событие недоступности правило 31 пропустит, а «Node up» при восстановлении придёт всё равно. Для нод без primary IP этого не случится, но если позже добавите в группу ноду за маршрутизатором или коммутатором — одинокое «Node up» вернётся.