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

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

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

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

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

По шторм-детектору: вы его не пропустили — он не сработал, потому что выключен по умолчанию (EventStorm.EnableDetection = 0). Готового правила в EPP под него тоже нет — из коробки есть только шаблон события SYS_EVENT_STORM_DETECTED.

Как это работает, если включить: сервер раз в секунду сравнивает поток событий с порогом EventStorm.EventsPerSecond (по умолчанию 1000 в секунду). Если поток держится выше порога дольше EventStorm.Duration (15 секунд), генерируется SYS_EVENT_STORM_DETECTED, и дальше сервер просто отбрасывает все входящие события, пока поток не упадёт ниже порога — тогда SYS_EVENT_STORM_ENDED и нормальная работа. То есть это не мониторинг, а предохранитель: вашу петлю он бы разорвал, но на время шторма мониторинг слепнет — отбрасываются все события, не только «лишние».

Что сделать:

• Сначала померьте нормальный поток: DCI на объекте сервера с internal-параметром Server.TotalEventsProcessed и обработкой «average delta per second» покажет события в секунду. Порог ставьте с запасом выше нормальных пиков — дефолтные 1000/с для вашей инсталляции почти наверняка слишком высоко, ваша петля могла до них и не дотягивать.
• EventStorm.EnableDetection = 1, порог и длительность — по результатам замера. Все три параметра требуют рестарта сервера.
• Правило в EPP на SYS_EVENT_STORM_DETECTED с алармом или нотификацией — иначе детектор молча отбросит события, и вы узнаете постфактум.

На тот же DCI стоит повесить и обычный threshold — он даст раннее предупреждение на уровне сильно ниже шторма и ничего при этом не отбрасывает.

По галочкам Replace: нет, здесь они бы ничего не изменили. Replace управляет только конфликтами: если объект с таким GUID/именем на сервере уже есть, с галочкой он перезаписывается версией из файла, без — остаётся как был, версия из файла пропускается. Объектов, которых на сервере нет, это не касается — они создаются всегда, независимо от галочек. Ваше событие потерялось не из-за этого — его не было на сервере в момент импорта правил, это и есть тот тикет про импорт.

Но одно следствие проверьте: на свежей инсталляции стандартные события, правила EPP и темплейты уже существуют. Если на старом сервере вы меняли что-то стандартное — severity системных событий, дефолтные правила, — то при импорте без Replace эти изменения молча не применились, остались свежие дефолтные версии.