В продолжение темы:
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 эти изменения молча не применились, остались свежие дефолтные версии.
Но одно следствие проверьте: на свежей инсталляции стандартные события, правила EPP и темплейты уже существуют. Если на старом сервере вы меняли что-то стандартное — severity системных событий, дефолтные правила, — то при импорте без Replace эти изменения молча не применились, остались свежие дефолтные версии.
----------
Именно так и делал. Проверю