NetXMS Support Forum

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


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

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

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

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

Ошибки при создании правила не было. Список событий у правила сейчас пустой, а пустой список в EPP означает "любое событие" — на скриншоте в разделе Events так и написано, "Any event". После импорта правило 96 создаёт аларм на каждое событие от всех объектов из своего списка source.

Отсюда же и скачки статуса, про которые вы писали в первом сообщении. Это не отдельная проблема, а следствие той же поломки — цикл замыкается сам на себя:

• Любое событие от ноды из списка попадает в правило 96, создаётся аларм severity MINOR.
• Статус объекта считается как максимум из расчётного статуса и severity самого критичного активного аларма, поэтому нода уходит NORMAL → MINOR.
• Смена статуса генерирует SYS_NODE_MINOR.
• Это событие снова попадает в правило 96 — оно же ловит любое событие.
• Парное правило "Terminate telegram alarm when CPU usage is normal" потеряло своё событие точно так же и тоже ловит любое. Оно закрывает аларм, статус падает обратно в NORMAL, генерируется SYS_NODE_NORMAL.
• Дальше по кругу, со скоростью обработки событий.

В логе это видно напрямую: у события SYS_NODE_MINOR стоит lastAlarmKey "High_cpu_usage_ТРК сервер офис_0x0000010C", то есть событие смены статуса обработано именно правилом про CPU.

Семь миллионов ID сожгла именно пара create + terminate. Если бы аларм только создавался, при одинаковом alarm key сервер увеличивал бы repeat count у существующего аларма и новый ID не выделял. Но парное правило каждый раз закрывает аларм, поэтому следующее событие заводит новый.

Что сделать:

• Проверьте все правила, а не только эти два. Импорт молча выбрасывает ссылки на события, которых нет на целевом сервере, и правило остаётся включённым с урезанным списком. Если выпали все события — правило становится catch-all. Пройдитесь по списку правил и посмотрите, где список событий пуст.
• В первую очередь те, что создают алармы или шлют нотификации. У них такая поломка даёт не лишние срабатывания, а вот такой шторм.
• При переносе на новую инсталляцию custom-события и правила должны быть в одном экспорт-файле. Внутри файла порядок правильный, события импортируются раньше правил. Ломается, когда правила и события уезжают разными файлами и правила импортируются первыми — на момент импорта правил событий ещё нет.

База сама не почистится. Рост прекратится, как только уберёте catch-all правила, а накопленные алармы и event log будет разгребать housekeeper по настройкам retention — на семи миллионах записей это не быстро.

На сам импорт завёл тикет — молча терять ссылки на события и оставлять правило включённым он не должен: https://github.com/netxms/netxms/issues/3443