NetXMS Support Forum

Thank you very much.

Можно обойтись одной парой. Ключи таймеров и алармов у вас содержат %n_%i, то есть уникальны для каждой ноды — при объединении правил конфликта не будет.

Флаг "Accept correlated events" не переключает правило в другой режим, он только дополнительно разрешает коррелированные события. Некоррелированные обрабатываются в любом случае. Собственное SYS_NODE_DOWN прокси-ноды некоррелированное, SYS_NODE_UNREACHABLE ноды за прокси — коррелированное, поэтому одно правило с включённым флагом покрывает оба случая.

Чтобы слить 31/33 в одно правило: в фильтре указать обе группы (Node by tunnel epp и Node behind the proxy epp) или вообще убрать фильтр по объектам, включить "Accept correlated events", оставить скрипт с проверкой maintenance. То же самое с 32/34.

Две пары имеет смысл держать в двух случаях:

- нужны разные задержки — сейчас у вас 5 минут для прокси и 10 для подчинённых нод; в одном правиле останется одна;
- нужно ограничить действие флага узким списком нод. SYS_NODE_UNREACHABLE коррелируется не только при падении прокси, но и при падении маршрутизатора или коммутатора на пути. Правило с флагом, охватывающее все ноды, при падении коммутатора сработает на каждой ноде за ним — вместо одного письма о коммутаторе придёт письмо на каждую недоступную ноду. Пока в группах только ноды за прокси, этого не случится, но при расширении фильтра на всё дерево — случится.

Отдельно про правила 32/34 (Node up). SYS_NODE_UP не коррелируется никогда, кроме одного случая: все события от объекта в maintenance mode считаются коррелированными. Отсюда сценарий: нода упала (таймеры созданы), после этого её перевели в обслуживание, она поднялась — правило Node up событие пропустит, аларм не закроется и отложенные действия не отменятся, и через 8 часов придёт письмо о недоступности уже работающей ноды. Так что на правилах Node up флаг "Accept correlated events" лучше тоже включить — во всех остальных ситуациях он там ни на что не влияет.

Ошибки при создании правила не было. Список событий у правила сейчас пустой, а пустой список в 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

Проверил. Все работает. Спасибо.

Появился вопрос: а нужно ли вообще 2 пары правил epp создавать (для прокси нод и для над за прокси)?
Или можно обойтись одной парой правил?

С учетом полученной информации получились такие правила.
Опцию "Accept correlated events" включал только на правиле 33 Mail alarm when the node behind the proxy is down in 600 sec (или Уведомление по почте при отключении ноды за прокси-сервером в течение 600 секунд).
Пока еще проверяю во всех режимах

The walks confirm it, and both chassis behave identically. xA hears its own chassis ID (AC:5E:14:7F:89:01) on local ports 1 and 123; xB hears its own (AC:5E:14:7F:74:01) on local ports 1 and 51. In each case one entry points at 10GE2/0/1 and the other at MEth0/0/0, so the two ports see each other. Everything else in both walks is clean - all six Eth-Trunk0 members, the 10GE4/0/47 keepalive and the downstream CE8865 / CE6857E / H3C links resolve correctly in both directions.

You are right that there is no cable between those two ports, and there doesn't need to be. LLDP only requires them to be in the same broadcast domain. Here's what's actually happening:

LLDP frames are sent to 01-80-C2-00-00-0E, which is nearest-bridge scope - a standards-compliant bridge consumes them and never forwards them. So whatever sits between MEth0/0/0 and 10GE2/0/1 either ignores that rule (unmanaged switch, media converter, patch through a passive device) or is explicitly configured to tunnel LLDP. Both ports having exactly one neighbour each - each other - rules out a managed LLDP-speaking switch in between, because then both would show that switch instead.

To pin down which one:

display lldp neighbor interface MEth0/0/0
display lldp neighbor interface 10GE2/0/1
display l2protocol-tunnel group-mac all          # LLDP tunneling configured?
reset lldp statistics interface 10GE2/0/1        # then re-check counters
display lldp statistics interface 10GE2/0/1      # frames still arriving = live path, not stale table

Also check the running config for l2protocol-tunnel lldp enable or link-protocol transport lldp anywhere on the management path.

Note: the description configured on 10GE2/0/1 reads TO_XM-GL-HX-xA_MEth0/0/0 on xA and TO_XM-GL-HX-xB_MEth0/0/0 on xB, which suggests this path was built deliberately. Descriptions go stale, so treat it as a hint rather than proof - but both chassis being labelled and behaving the same way makes an accident unlikely. Worth asking whoever cabled the management network.

If the path is intentional, the LLDP data is correct and the link can be ignored; disabling LLDP on MEth0/0/0 suppresses it.

Separately, NetXMS should not display a node as its own peer no matter what the device reports. STP discovery already filters this case, LLDP does not - that's a bug on our side, filed as https://github.com/netxms/netxms/issues/3439

Thank you very much. The physical topology is shown in the figure. There is no physical link between MEth0/0/0 and 10GE2/0/1. The SNMP logs have been uploaded. Could you please help analyze and provide guidance? I would highly appreciate your support!

В 6.2.2 должно исправится.

Понял.

Один нюанс: события от узлов в режиме обслуживания тоже считаются коррелированными, поэтому правило с включённым флагом будет срабатывать и во время maintenance. Если это нежелательно, добавьте в фильтрующий скрипт правила проверку [tt]return !$object->isInMaintenanceMode;[/tt] (это атрибут, без скобок).

Опробую это. Отпишу

Коррелированное событие — это событие, для которого сервер уже определил причину и привязал его к корневому событию. Так происходит в нескольких случаях: недоступность узла за прокси/маршрутизатором/коммутатором привязывается к событию падения этого прокси или коммутатора; interface down, SNMP fail, service down на узле, который сам недоступен, привязываются к его же SYS_NODE_DOWN; все события от объекта в режиме обслуживания привязываются к событию входа в maintenance.

По умолчанию правила EPP такие события пропускают, и это осознанное поведение: уведомлять нужно о причине, а не о каждом следствии. Упал коммутатор — приходит одно уведомление о коммутаторе, а не сотня о каждом узле за ним.

Поэтому всегда включать этот флаг не нужно. Включайте его только в правилах, которые должны отработать на каждом событии независимо от того, есть ли у него известная причина: учёт простоя (стандартные правила Start/End downtime), создание аварий и блокирующих таймеров по каждому узлу — ваш случай с правилом 33. В обычных уведомляющих правилах флаг лучше оставить выключенным, иначе вернётся шквал уведомлений о следствиях.

Один нюанс: события от узлов в режиме обслуживания тоже считаются коррелированными, поэтому правило с включённым флагом будет срабатывать и во время maintenance. Если это нежелательно, добавьте в фильтрующий скрипт правила проверку [tt]return !$object->isInMaintenanceMode;[/tt] (это атрибут, без скобок).