NetXMS Support Forum

Теперь понятнее. Точно лучше отдельные правила для прокси и нод за прокси

С учетом полученной информации оставлю 2 пары правил.
На все ноды правила распространять не буду так как не по всем нужны уведомления.
Я правильно понял что при таком раскладе на всех 4 правилах нужно включить опцию приема кореллированных событий и скрипт с проверкой maintenance?

Проверил. Все работает. Спасибо.

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

С учетом полученной информации получились такие правила.
Опцию "Accept correlated events" включал только на правиле 33 Mail alarm when the node behind the proxy is down in 600 sec (или Уведомление по почте при отключении ноды за прокси-сервером в течение 600 секунд).
Пока еще проверяю во всех режимах

Понял.

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

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

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

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

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

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

В продолжение темы:
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 гб.


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

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

Прикладываю лог событий и лог аварий по узлам ТРК сервер офис (прокси нода) и ТРК сервер 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

Итоги проверки:
- нет ли выше (правила 1–30) правила с флагом "Stop event processing", под которое попадает SYS_NODE_UNREACHABLE от этих узлов;

Не нашел такого.
Но нашел другие правила (NEW Telegram alarm when Интернет резерв is stop responding ICMP и NEW Telegram alarm when Интернет резерв is start responding ICMP). Я создавал его когда пытался отключить уведомления от подчиненных нод за прокси при пропадании интернета.
Убрал из секции cancel the following timers таймеры по этим нодам. Может они влияли еще. Теперь эти правила выглядят так (новые правила NEW Telegram alarm when Интернет резерв).

1. Понял. Учту.
2. Пока проверяю, отпишу. Вот характерный пример уведомлений. Выключил службу агента на прокси ноде ТРК сервер офис. Подождал 5 мин и включил службу агента на прокси ноде ТРК сервер офис. Итог уведомлений:
⌛ 18.Jul.2026 16:52:10
Severity Critical 🔴
ТРК сервер офис
👉 Node unreachable because of network failure

⌛ 18.Jul.2026 16:58:28
Severity Normal 🟢
ТРК сервер KMS
👉 Node up

⌛ 18.Jul.2026 16:58:38
Severity Normal 🟢
ТРК сервер офис
👉 Node up

Т.е. сначала приходит уведомление от ноды за прокси ТРК сервер KMS (хотя уведомления быть не должно так как там таймер 600 сек) а потом уже от прокси ноды ТРК сервер офис.

3. Понял. Создам отельную тему.

Отправляю скришоты alarm log с прокси ноды и ноды за прокси (подчиненной).
Что еще можно проверить?

Отправляю скриншоты правил уведомлений и логов событий.
Правила уведомления изменил на SYS_NODE_DOWN / SYS_NODE_UNREACHABLE, а когда нода поднимается обратно то SYS_NODE_UP.