NetXMS Support Forum

Понял.

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

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

Коррелированное событие — это событие, для которого сервер уже определил причину и привязал его к корневому событию. Так происходит в нескольких случаях: недоступность узла за прокси/маршрутизатором/коммутатором привязывается к событию падения этого прокси или коммутатора; interface down, SNMP fail, service down на узле, который сам недоступен, привязываются к его же SYS_NODE_DOWN; все события от объекта в режиме обслуживания привязываются к событию входа в maintenance.

По умолчанию правила EPP такие события пропускают, и это осознанное поведение: уведомлять нужно о причине, а не о каждом следствии. Упал коммутатор — приходит одно уведомление о коммутаторе, а не сотня о каждом узле за ним.

Поэтому всегда включать этот флаг не нужно. Включайте его только в правилах, которые должны отработать на каждом событии независимо от того, есть ли у него известная причина: учёт простоя (стандартные правила Start/End downtime), создание аварий и блокирующих таймеров по каждому узлу — ваш случай с правилом 33. В обычных уведомляющих правилах флаг лучше оставить выключенным, иначе вернётся шквал уведомлений о следствиях.

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

Вроде нашел подходящее правило. В чем я мог ошибиться при его создании?
Цель правила: если на сервере 15 мин и более наблюдается загрузка ЦП более 90% то отправляется уведомление.

UPD. Нашел в чем проблема. При экспорте-импорте на новую инсталляцию Netxms потерялось событие которое добавлял вручную. Пока отключил правило. Позже исправлю и проверю остальные правила на предмет таких же нестыковок

На первый взгляд работает. Проверю более тщательно и отпишу.

Попутно вопрос: как понять параметр "accept corellated event"? Его лучше всегда включать в правилах epp?

Начиная с 5.2 статусный опрос сам запускает пересинхронизацию интерфейсов, если считает, что устройство перезагрузилось (коммит 4943ddf210, NX-2728). Перезагрузка определяется сравнением вычисленного времени старта системы (текущее время минус sysUpTime), а это значение из-за округления и сетевых задержек гуляет на 1–2 секунды между опросами. Любой сдвиг вперёд трактуется как рестарт — и выполняется полная синхронизация интерфейсов, которая не проверяет галочку запрета опроса конфигурации. Поэтому VLAN'ы возвращаются даже с установленной галочкой, обычно в течение нескольких минут: статусный опрос по умолчанию идёт раз в 60 секунд, отсюда и впечатление, что это происходит при раскрытии ноды.

По ISW002 (VLAN 3385–3418) по коду вижу два возможных пути: либо для этих интерфейсов не удалось запустить хук-скрипт (в этом случае интерфейс сейчас создаётся без проверки), либо они не создавались заново, а обновились по ifIndex — обновление существующего объекта хук не вызывает. Чтобы понять, какой вариант у вас, включите в netxmsd.conf отладку:

DebugTags = poll.status:5,node.iface:7
и после следующего появления VLAN'ов пришлите фрагмент лога по этой ноде — интересуют строки "system restart detected" и "accepted/rejected by filter".

Хук пока оставьте.

В продолжение темы:
https://www.netxms.org/forum/oe-oo/shkval-opoveschenij-posle-poteri-kontakta-s-proksi-nodoj/15/

3. Отдельная и более серьёзная проблема — шторм аварий.

08.07 ID аварий были в районе 43, 15.07 — уже 7 197 667. Семь миллионов аварий за неделю. В логах видно почему: статус узла скачет NORMAL↔MINOR десятки раз в секунду (события SYS_NODE_MINOR / SYS_NODE_NORMAL с тегом NodeStatus), и на каждое такое событие создаётся авария. Это и есть причина постоянного роста базы и ошибок в alarm log. Покажите правило, которое создаёт аварии на события изменения статуса узла — скорее всего, его нужно убрать или сильно ограничить. И надо разбираться, почему статус так флапает — это лучше вынести в отдельную тему.

----------------
то и есть причина постоянного роста базы и ошибок в alarm log.
--------------------

Тут не совсем так. На проблемной инсталляции база росла с 23 гб до 120 за 1-2 дня.
Сейчас новой инсталляции сервера уже больше недели и база занимает 18 гб.


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

Проверяю. Отпишу

Проблема в коррелированных событиях. Когда узел за прокси становится недоступен, сервер связывает его SYS_NODE_UNREACHABLE с корневым событием прокси. Правила EPP по умолчанию пропускают коррелированные события — правило обрабатывает их только если в его свойствах включена опция "Accept correlated events". У стандартных правил (например, 85 "Start downtime") она включена — поэтому в фильтре видно "including correlated events". У ваших правил 31/33/34 её нет.

Отсюда всё поведение из вашего лога: событие недоступности "ТРК сервер KMS" не совпало ни с одним из ваших правил (только со стандартными 2/58/86), поэтому не создались ни аварии, ни блокирующие таймеры. А SYS_NODE_UP при восстановлении не коррелируется никогда — правило 34 срабатывает и сразу шлёт "Node up", блокировать его нечем. У прокси всё работает, потому что его собственное событие недоступности не коррелированное.

Что сделать: откройте свойства правила 33 и включите "Accept correlated events". После этого при коротком обрыве прокси таймер будет создаваться и уведомление "Node up" от подчинённых узлов будет блокироваться — так же, как сейчас у прокси.

Один нюанс: при длительном обрыве прокси подчинённые узлы теперь тоже пришлют отложенные уведомления о недоступности (Critical MailAlarm через 10 минут и далее). Если они не нужны — учтите, что просто выключить эти действия нельзя: неактивное действие не создаёт таймер, и блокировка перестанет работать. В этом случае вместо уведомления назначьте отложенным действием с тем же ключом таймера какое-нибудь пустое действие.

Изменённые правила 27/28 по "Интернет резерв" теперь на основную схему не влияют.

Прикладываю лог событий и лог аварий по узлам ТРК сервер офис (прокси нода) и ТРК сервер KMS (подчиненная нода за прокси). Тестировал так: на сервере ТРК сервер офис останавливал службу NetXMS Agent на 1,5-2 мин и включал снова.
Как итог: приходит уведомление только от подчиненной ноды ТРК сервер KMS
⌛ 18.Jul.2026 17:47:50
Severity Normal 🟢
ТРК сервер KMS
👉 Node up

- после обрыва (пока не прошли 10 минут) откройте список Scheduled Tasks и проверьте, есть ли отложенная задача Execute.Action с ключом вида SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_<имя узла>_<0x...>.

скриншот прикладываю

- включите в конфиге сервера DebugTags=event.policy:6, воспроизведите обрыв и посмотрите в логе строки "match EPP rule" для события SYS_NODE_UNREACHABLE — будет видно, какие правила его обработали;

Отредактировал файл netxmsd.conf как на скриншоте, перезапустил сервер.
Но этого

и посмотрите в логе строки "match EPP rule" для события SYS_NODE_UNREACHABLE — будет видно, какие правила его обработали

не нашел.
Искал на ноде с помощью Log - Events.

Или имелось в виду лог сервера в файле в Ubuntu?
В логе сервера netxmsd нашел такие строки:
2026.07.18 17:30:14.313 *D* [event.policy       ] Action 8 execution blocked by timer "SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_ТРК сервер офис_0x0000010C" key
2026.07.18 17:30:14.313 *D* [event.policy       ] Action 15 will not be executed, because id disabled
2026.07.18 17:30:14.313 *D* [event.policy       ] Action 16 will not be executed, because id disabled
2026.07.18 17:30:14.313 *D* [event.policy       ] Action 17 will not be executed, because id disabled
2026.07.18 17:30:14.321 *D* [event.policy       ] Delayed action execution with key "SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_1_DAY_ТРК сервер офис_0x0000010C" cancelled
2026.07.18 17:30:14.325 *D* [event.policy       ] Delayed action execution with key "SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_3_DAYS_ТРК сервер офис_0x0000010C" cancelled
2026.07.18 17:30:14.328 *D* [event.policy       ] Delayed action execution with key "SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_8_HOURS_ТРК сервер офис_0x0000010C" cancelled
2026.07.18 17:30:14.332 *D* [event.policy       ] Delayed action execution with key "SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_ТРК сервер офис_0x0000010C" cancelled
2026.07.18 17:30:14.332 *D* [event.policy       ] Event 10517520 match EPP rule 86
2026.07.18 17:30:14.332 *D* [event.policy       ] Requesting downtime "NODE_DOWN" end for object ТРК сервер офис [268]
2026.07.18 17:30:15.815 *D* [event.policy       ] Event 10517519 match EPP rule 58
2026.07.18 17:30:25.251 *D* [event.policy       ] Event 10517529 match EPP rule 2
2026.07.18 17:30:25.251 *D* [event.policy       ] Event 10517529 match EPP rule 86



2026.07.18 17:31:15.102 *D* [event.policy       ] Requesting downtime "NODE_DOWN" end for object ТРК сервер KMS [403]
2026.07.18 17:31:17.854 *D* [event.policy       ] Event 10517615 match EPP rule 58
2026.07.18 17:31:19.144 *D* [event.policy       ] Event 10517618 match EPP rule 2
2026.07.18 17:31:19.144 *D* [event.policy       ] Event 10517618 match EPP rule 86