Настройками шквал "Node up" убирается так:

1. В Server Configuration задать Beacon.Hosts — два-три внешних адреса через запятую (не шлюз локальной сети, он при пропаже интернета продолжит отвечать) — и перезапустить сервер. При потере связи со всеми адресами сервер генерирует SYS_NETWORK_CONN_LOST, при восстановлении — SYS_NETWORK_CONN_RESTORED; стандартные правила держат на это время аларм с ключом NET_CONN_LOST.
2. Добавить правило на SYS_NETWORK_CONN_RESTORED, выше стандартного "Terminate NetXMS server network connection loss alarm when connection restored": действие DoNothing, Delayed by 15m, timer key UPLINK_RECOVERY.
3. Из правил 26, 32 и 34 вынести Normal MailAlarm (вместе с его "Do not run if timer ... is active") в отдельное правило, стоящее непосредственно перед исходным: те же source и event, флаг "Accept correlated events" как у исходного, "Stop event processing" не включать. В исходном остаются Terminate alarms, DoNothing и Cancel timers.
4. В каждом из трёх новых правил — filtering script:

   return FindAlarmByKey("NET_CONN_LOST") == null && CountScheduledTasksByKey("UPLINK_RECOVERY") == 0;
   

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

Note: в течение 15 минут после восстановления связи письма "Node up" и "icmp ok" не отправляются вообще, в том числе от нод, которые в это время действительно поднялись. Алармы при этом закрываются как обычно.

09.Aug.2026 17:01:58
Service is still unreachable for 1 day
Severity Critical 🟡
***** компьютер архивов
Node unreachable because of network failure

ну это не страшно

В логе уведомлений сервера это видно напрямую: строки 459–463 за 19:01:33–19:01:39, событие SYS_NODE_UP, Rule ID e8f2ab80-3472-4631-a7a6-e501149eb086, описание правила "Terminate mail alarms when node connected by tunnel / proxy node is up in 300 sec" — это правило 32. Пять уведомлений, все "Node up", ни одного "down".

Режим обслуживания ничего не подавляет на этапе генерации событий. События создаются, пишутся в event log и попадают в EPP как обычно; единственное, что делает maintenance — проставляет каждому событию объекта Root ID, равный ID события входа в обслуживание. Дальше решает флаг "Accept correlated events" на правилах.

В вашем логе событий: SYS_MAINTENANCE_MODE_ENTERED в 18:38:27 с Root ID = 0, а всё последующее — SYS_TUNNEL_CLOSED 18:58:20, SYS_AGENT_UNREACHABLE и SYS_NODE_UNREACHABLE 19:00:23, SYS_TUNNEL_OPEN 19:00:45, SYS_NODE_UP и SYS_AGENT_OK 19:01:33 — с Root ID = 11094369. Все коррелированные.

Отсюда цепочка:

1. SYS_NODE_UNREACHABLE коррелированное, у правила 31 флаг выключен — правило его пропустило. Ни аларм, ни таймер NODE_BY_TUNNEL_DOWN_%n_%i не создались.
2. SYS_NODE_UP тоже коррелированное, но у правила 32 флаг включён — правило сработало.
3. У действия Normal MailAlarm в правиле 32 стоит блокировка "Do not run if timer NODE_BY_TUNNEL_DOWN_%n_%i is active". Таймера нет, потому что его никто не создавал — блокировка не сработала, письмо ушло.

Что сделать: выключить "Accept correlated events" на правилах 32 и 34. Скрипт с проверкой maintenance добавлять никуда не нужно — он дал бы тот же результат, но флаг проще.

Здесь нужно поправить то, что я писал 21.07. Флаг на up-правилах рекомендовался ради сценария "нода упала (таймеры заведены) → её перевели в обслуживание → она поднялась в обслуживании → аларм не закрылся, и через 8 часов пришло письмо". Этот сценарий сервер закрывает сам: при выходе из обслуживания состояние ноды восстанавливается на то, каким оно было до входа, и если оно разошлось с фактическим — принудительно запускается status poll. В этом сценарии состояния разойдутся, поллинг отработает и сгенерируется новое, уже некоррелированное SYS_NODE_UP: правило 32 на нём сработает, аларм закроется, таймеры снимутся. Флаг для этого не нужен, а его единственный реальный эффект — ровно то, что вы получили 06.08.

Два соседних случая, чтобы было понятно, чего ждать после выключения флага:

• Нода и упала, и поднялась внутри окна обслуживания (ваш случай 06.08). Состояние на выходе совпадает с исходным, поллинг не форсируется, после выхода из обслуживания ничего не приходит. Аларма и таймеров при этом не создавалось — закрывать нечего.
• Нода упала в обслуживании и осталась лежать. Состояния разойдутся, форсированный поллинг отработает, и SYS_NODE_UNREACHABLE придёт уже некоррелированным — реальную аварию за окном обслуживания вы не потеряете.

Вне обслуживания SYS_NODE_UP не коррелируется никогда, поэтому на обычную работу правил 32/34 выключенный флаг не влияет.

Правила 31 и 33 трогать не нужно. У 31 флаг выключен, у 33 включён вместе со скриптом проверки maintenance — оба во время обслуживания молчат.

Note: одна дырка остаётся. Отложенные действия, заведённые до входа в обслуживание, во время обслуживания не отменяются и не проверяют maintenance при срабатывании — их снимет только SYS_NODE_UP после выхода. У вас Critical MailAlarm стоит с задержкой 5 минут, поэтому сценарий "нода упала, её в течение 5 минут перевели в обслуживание, и там же она поднялась" всё равно даст письмо о недоступности. Задержки 8h/1d/3d сработают только если окно обслуживания окажется длиннее них.

Отдельно: в моём ответе от 28.07 было сказано, что асимметрия между правилами 31 и 32 проявится только если в группу добавить ноду за маршрутизатором или коммутатором, и что для нод без primary IP этого не случится. Это неверно — режим обслуживания коррелирует все события объекта независимо от primary IP и от топологии, поэтому асимметрия проявляется в любое окно обслуживания. Ровно это 06.08 и произошло.

То, что maintenance подавляет события через корреляцию, а не отдельным механизмом, в трекере уже разбиралось: https://github.com/netxms/netxms/issues/2571 — закрыто как expected behavior, с тем же обходным путём через скрипт. В документации раздел про maintenance mode при этом сформулирован неверно: там сказано, что события не генерируются, тогда как они генерируются и коррелируются. Завёл тикет: https://github.com/netxms/netxms-doc/issues/63

Вопрос: может на правиле 31 Mail alarm when the node behind the proxy is down in 7 min нужно включить скрипт проверки что нода не в режиме обслуживания?

Выбор события определяет не тоннель сам по себе, а наличие у ноды 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» вернётся.

Уведомления о недоступности этой ноды не было. Эта нода включена в шаблон Node by tunnel epp. Нода не является прокси но подключена через тунель

Вот так выглядели уведомления:
26.Jul.2026 17:26:27
Severity Major
ТРК интернет
Node is unreachable by ICMP

===========================>>> Тут не хватает уведомления о недоступности прокси ноды ТРК сервер офис

26.Jul.2026 17:26:02
Severity Critical
ТРК сервер KMS
Node unreachable because of network failure

26.Jul.2026 18:26:57
Severity Normal 🟢
ТРК интернет Роктел
Node started responding to ICMP

26.Jul.2026 18:27:15
Severity Normal 🟢
ТРК сервер офис
Node up

26.Jul.2026 18:27:34
Severity Normal 🟢
ТРК сервер KMS
Node up

Поэтому пара 25/26 — тот же случай, что 31/32, и логика распределяется так же:

• Правило 25 без флага: в нормальной работе события некоррелированные, правило срабатывает всегда. В maintenance они становятся коррелированными, и правило само их пропустит — скрипт с проверкой не нужен.
• Правило 26 с флагом: нужен ровно для сценария «интернет упал (аларм создан, таймеры 8h/1d/3d заведены) → ноду перевели в обслуживание → интернет восстановился». Без флага icmp ok будет пропущено, аларм останется висеть, и через 8 часов придёт письмо о недоступности уже работающего интернета.

Одно замечание на будущее: системное SYS_ICMP_UNREACHABLE при падении ноды коррелируется к её SYS_NODE_DOWN, а ваш кастомный icmp unreachable — нет. Если нода, на которой висит этот DCI, упадёт целиком, придут оба уведомления — и о ноде, и об интернете. Для порогов с кастомными событиями корреляция такие следствия не гасит.

Вопрос: с учетом полученной информации выше я включил прием кореллированных событий только на правиле 26 Mail alarm when Internet is start responding ICMP. Это верный подход?

• 31 (прокси down) — флаг выключен, скрипта нет
• 32 (прокси up) — флаг включён, скрипта нет
• 33 (нода за прокси down) — флаг включён + скрипт maintenance
• 34 (нода за прокси up) — флаг включён, скрипта нет

Ключи таймеров и алармов между парами согласованы (NODE_BY_TUNNEL_DOWN_* в 31/32, NODE_BEHIND_THE_PROXY_DOWN_* в 33/34), а Terminate alarms и Cancel timers в up-правилах перекрывают все ключи из down-правил. Работать будет как задумано.

Одна мелочь, ни на что не влияет: в фильтре правила 31 рядом с SYS_NODE_DOWN стоит SYS_NODE_UNREACHABLE. Для ноды, подключённой напрямую по тоннелю, недоступность — это SYS_NODE_DOWN; SYS_NODE_UNREACHABLE у неё не возникает, а если бы возникло — оно коррелированное и при выключенном флаге всё равно было бы пропущено. Можно оставить как есть.

Теперь все корректно?

• 33 (нода за прокси, down) — флаг ON + скрипт maintenance
• 31 (прокси, down) — ни флага, ни скрипта
• 32 / 34 (up) — флаг ON, скрипт не добавлять

Почему по-разному:

Down. У ноды за прокси событие SYS_NODE_UNREACHABLE коррелированное — без флага правило 33 не сработает вообще. Раз флаг включён, правило начнёт срабатывать и во время обслуживания, поэтому там нужен return !$object->isInMaintenanceMode;. У прокси собственное SYS_NODE_DOWN некоррелированное, обрабатывается и без флага; а в режиме обслуживания его события становятся коррелированными, и правило само их пропустит — ни скрипт, ни флаг там не нужны.

Up. SYS_NODE_UP коррелируется только когда нода в maintenance — и это ровно тот случай, ради которого флаг включается: нода поднялась в обслуживании, правило должно пропустить событие, закрыть аларм и снять отложенные действия. Если добавить туда проверку maintenance, правило пропустит это событие мимо, аларм не закроется, и через 8 часов придёт письмо о работающей ноде — вернётся исходный баг.

Флаг "Accept correlated events" не переключает правило в другой режим, он только дополнительно разрешает коррелированные события. Некоррелированные обрабатываются в любом случае. Собственное SYS_NODE_DOWN прокси-ноды некоррелированное, SYS_NODE_UNREACHABLE ноды за прокси — коррелированное, поэтому одно правило с включённым флагом покрывает оба случая.

Чтобы слить 31/33 в одно правило: в фильтре указать обе группы (Node by tunnel epp и Node behind the proxy epp) или вообще убрать фильтр по объектам, включить "Accept correlated events", оставить скрипт с проверкой maintenance. То же самое с 32/34.

Две пары имеет смысл держать в двух случаях:

• нужны разные задержки — сейчас у вас 5 минут для прокси и 10 для подчинённых нод; в одном правиле останется одна;
• нужно ограничить действие флага узким списком нод. SYS_NODE_UNREACHABLE коррелируется не только при падении прокси, но и при падении маршрутизатора или коммутатора на пути. Правило с флагом, охватывающее все ноды, при падении коммутатора сработает на каждой ноде за ним — вместо одного письма о коммутаторе придёт письмо на каждую недоступную ноду. Пока в группах только ноды за прокси, этого не случится, но при расширении фильтра на всё дерево — случится.

Отдельно про правила 32/34 (Node up). SYS_NODE_UP не коррелируется никогда, кроме одного случая: все события от объекта в maintenance mode считаются коррелированными. Отсюда сценарий: нода упала (таймеры созданы), после этого её перевели в обслуживание, она поднялась — правило Node up событие пропустит, аларм не закроется и отложенные действия не отменятся, и через 8 часов придёт письмо о недоступности уже работающей ноды. Так что на правилах Node up флаг "Accept correlated events" лучше тоже включить — во всех остальных ситуациях он там ни на что не влияет.

Появился вопрос: а нужно ли вообще 2 пары правил epp создавать (для прокси нод и для над за прокси)?
Или можно обойтись одной парой правил?

Один нюанс: события от узлов в режиме обслуживания тоже считаются коррелированными, поэтому правило с включённым флагом будет срабатывать и во время maintenance. Если это нежелательно, добавьте в фильтрующий скрипт правила проверку [tt]return !$object->isInMaintenanceMode;[/tt] (это атрибут, без скобок).

Опробую это. Отпишу