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

[Stanislav]

а это время в 5 минут - оно в свойствах экшна настроено?

Да.

Экшн при потере контакта
https://drive.google.com/file/d/1o4BwNM8HnuWaRQPScepYWZYPvQbMOYbo/view?usp=sharing

Экшн при возобновлении контакта
https://drive.google.com/file/d/1qC6ov1e5h5ORca-rJ1U9YKdXMS5TAXgm/view?usp=sharing

какая точно версия NetXMS?

5.2.6

можете показать для такой ситуации event log, отфильтрованный по двум нодам - прокси и какая-нибудь одна нода, которая за этой прокси? По идее события автоматически должны кореллироваться на SYS_NODE_DOWN этой прокси, но возможно что-то поломано.

event log прокси нода
https://drive.google.com/file/d/1At9jEzyr816qNNciSHviE1Blblwqq1-d/view?usp=sharing

event log нода
https://drive.google.com/file/d/1oot7rKzNgLHPh-uonKD-T0MYRs5Tr_5t/view?usp=sharing

Получил скриншоты следующим образом: остановил службу netxms agent на прокси ноде на 1 минуту. Потом включил службу netxms agent на прокси ноде. От прокси ноды уведомление не пришло зато пришло от подчиненной ноды что она  появилась в сети.

---

[Stanislav]

После обновления на 6.02 ситуация не изменилась

[Filipp Sudanov]

А как сконфигурированы прокси - они прописаны в свойствах ноды, или ноды в удаленных офисах выделены в зоны? Если второе, то прокси тоже нужно поставить тоже в эти зоны.

[Stanislav]

Второе.
"прокси тоже нужно поставить тоже в эти зоны."
Можно поподробнее со скриншотом?

[Stanislav]

Это имеете в виду?

---

[Filipp Sudanov]

Правой кнопкой по ноде, которая прокси, Change zone... и там выбрать зону.

Текущую зону ноды видно на закладке Overview в разделе Communications.

[Stanislav]

Сделал это, проверяю. Отпишусь.
Я наоборот понял из документации что прокси ноды всегда должны быть в зоне default.

[Stanislav]

Не помогло. что еще можно проверить?

[Filipp Sudanov]

Перечитал внимательно изначальное сообщение с логами событий - там на ноде не возникало события SYS_AGENT_UNREACHABLE, a было только SYS_NODE_UNREACHABLE - сервер понимает что из-за отсутствия прокси нода недоступна и не генерит отдельные события про агента.
Поэтому таймер не заводился и поэтому ничто не ограничивало отправку нотификации когда пришло SYS_AGENT_OK

[Stanislav]

А как можно это исправить настройками?
Я пробовал создавать правило уведомлений на другие события (SYS_NODE_DOWN, SYS_ICMP_UNREACHABLE) но это не помогло.

[Filipp Sudanov]

Основные события это SYS_NODE_DOWN / SYS_NODE_UNREACHABLE, а когда нода поднимается обратно то SYS_NODE_UP. Попробуйте на них настроить нотификации.

[Stanislav]

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

[Stanislav]

К сожалению это не помогло. Тестировал на версии 6.2.0

Правило уведомления для ноды за прокси
https://drive.google.com/file/d/1eUiX2z1VVnJh8BRj6kG7bmZ6xlkYg4BU/view?usp=drive_link

Лог событий от ноды за прокси
https://drive.google.com/file/d/1V0tSkzDTEGF6YIcRQHng8ONGnOegO8P6/view?usp=drive_link

Само уведомление (хотел сделать скриншот лога уведомлений с ноды но не нашел где это в новом клиенте)
https://drive.google.com/file/d/13kLb52E32amHju2tboypZiEgeWb-Pnza/view?usp=drive_link

Есть мысли что еще можно проверить?

[Stanislav]

Позже еще раз проверю и отпишу. Возникли сложности после обновления сервера до версии 6.2.0

[Filipp Sudanov]

Вероятно эти сложности: https://www.netxms.org/forum/general-support/issues-upgrading-from-netxms-server-6-1-4-to-6-2-0-via-apt-package-manager/msg35569/#msg35569

[Stanislav]

Нет. Хуже. База начала расти постоянно. При входе в logs - alarm выдавала ошибку базы данных.
Архив тоже оказался проблемным (не сразу заметил проблемы, и с базой из архива случились те же проблемы что и с рабочей базой).
Итог: установил новый сервер на базе последней сборки netxms (6.2.1) на актуальной ubuntu server (26.04 LTS).

Проблему наблюдаю ту же что изначально. Смена событий для нотификации на предложенные не помогла. Завтра постараюсь прислать скриншоты

[Stanislav]

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

---

[Stanislav]

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

---

[alk]

Спасибо за скриншоты, картина стала понятнее. По порядку:

1. Правила на SYS_AGENT_UNREACHABLE / SYS_AGENT_OK для узлов за прокси не будут работать в принципе.

Когда узел недоступен из-за прокси, сервер намеренно не генерирует SYS_AGENT_UNREACHABLE — причина недоступности уже известна, генерируется только SYS_NODE_UNREACHABLE. Но при восстановлении SYS_AGENT_OK генерируется. То есть таймер, который должен блокировать уведомление "появился в сети", никогда не создаётся. Старые телеграм-правила по SYS_AGENT_UNREACHABLE / SYS_AGENT_OK нужно отключить или убрать из них узлы за прокси — иначе они будут слать уведомления на каждый обрыв независимо от новых правил. Эту асимметрию (SYS_AGENT_OK без парного SYS_AGENT_UNREACHABLE) посмотрим на стороне сервера, возможно поправим.

2. Новые правила 33/34 настроены правильно, но по логам правило 33 не срабатывает.

Правило 33 должно создавать аварию на каждый SYS_NODE_DOWN / SYS_NODE_UNREACHABLE. События SYS_NODE_UNREACHABLE для "ТРК сервер KMS" за 12–15.07 в логе есть, а аварий по ним нет вообще (даже завершённых — для сравнения, авария от 08.07 по SYS_NODE_DOWN есть). Раз правило не сработало — таймер не создан, и "Node up" ничем не блокируется. Учтите также, что правила вы поменяли 16.07, а последний обрыв в логах — 15.07 22:18, то есть новые правила реальным обрывом ещё не проверялись.

Что проверить:

• нет ли выше (правила 1–30) правила с флагом "Stop event processing", под которое попадает SYS_NODE_UNREACHABLE от этих узлов;
• включите в конфиге сервера DebugTags=event.policy:6, воспроизведите обрыв и посмотрите в логе строки "match EPP rule" для события SYS_NODE_UNREACHABLE — будет видно, какие правила его обработали;
• после обрыва (пока не прошли 10 минут) откройте список Scheduled Tasks и проверьте, есть ли отложенная задача Execute.Action с ключом вида SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_<имя узла>_<0x...>.

После следующего обрыва пришлите лог событий и список аварий по зависимому узлу.

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

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

[Stanislav]

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. Понял. Создам отельную тему.