NetXMS Support Forum

Если применить этот подход к другим правилам самописным. Имеется 2 правила цель которых уведомлять что пинг на wan ip адрес роутера филиала стал недоступен.
Правило Правило 25 Mail alarm when Internet is not responding in 90 sec (Уведомление по почте что интернет недоступен через 90 сек)
Правило 26 Mail alarm when Internet is start responding ICMP (Уведомление по почте что интернет стал доступен).
Wan ip адреса роутеров пингую через субагент ping с сервера netxms и шаблоном распространяю на нужные ноды.

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

Вопрос: при импорте конфигурации на новый сервер нужно было во всех параметрах импорта устанавливать галочку в полях Replace?

Прикладываю скриншоты со старого и нового сервера

Да я понял. Уже проверил все правила которые создавал сам.
Проверю на всякий случай и остальные правила.

Вопрос: а можно на будущее как-то мониторить такие события? Есть правило по шторму событий. Оно не сработало или я пропустил его?

Получились такие правила.
31 прокси нода или нода подключенная через тунель недоступна. Убрал SYS_NODE_UNREACHABLE
32 прокси нода или нода подключенная через тунель доступна
33 нода за прокси недоступна
34 нода за прокси доступна

Да, всё верно — по всем четырём флаг и скрипт стоят правильно:

• 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 у неё не возникает, а если бы возникло — оно коррелированное и при выключенном флаге всё равно было бы пропущено. Можно оставить как есть.

Получились такие правила.
31 прокси нода или нода подключенная через тунель недоступна
32 прокси нода или нода подключенная через тунель доступна
33 нода за прокси недоступна
34 нода за прокси доступна

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

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

Не на всех — иначе сломается сценарий с maintenance, который чинили выше. По правилам:

• 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 часов придёт письмо о работающей ноде — вернётся исходный баг.

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