NetXMS Support Forum

Можно обойтись одной парой. Ключи таймеров и алармов у вас содержат %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

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

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

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

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

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

Начиная с 5.2 статусный опрос сам запускает пересинхронизацию интерфейсов, если считает, что устройство перезагрузилось (коммит 4943ddf210, NX-2728). Перезагрузка определяется сравнением вычисленного времени старта системы (текущее время минус sysUpTime), а это значение из-за округления и сетевых задержек гуляет на 1–2 секунды между опросами. Любой сдвиг вперёд трактуется как рестарт — и выполняется полная синхронизация интерфейсов, которая не проверяет галочку запрета опроса конфигурации. Поэтому VLAN'ы возвращаются даже с установленной галочкой, обычно в течение нескольких минут: статусный опрос по умолчанию идёт раз в 60 секунд, отсюда и впечатление, что это происходит при раскрытии ноды.

По ISW002 (VLAN 3385–3418) по коду вижу два возможных пути: либо для этих интерфейсов не удалось запустить хук-скрипт (в этом случае интерфейс сейчас создаётся без проверки), либо они не создавались заново, а обновились по ifIndex — обновление существующего объекта хук не вызывает. Чтобы понять, какой вариант у вас, включите в netxmsd.conf отладку:

DebugTags = poll.status:5,node.iface:7
и после следующего появления VLAN'ов пришлите фрагмент лога по этой ноде — интересуют строки "system restart detected" и "accepted/rejected by filter".

Хук пока оставьте.

Проблема в коррелированных событиях. Когда узел за прокси становится недоступен, сервер связывает его SYS_NODE_UNREACHABLE с корневым событием прокси. Правила EPP по умолчанию пропускают коррелированные события — правило обрабатывает их только если в его свойствах включена опция "Accept correlated events". У стандартных правил (например, 85 "Start downtime") она включена — поэтому в фильтре видно "including correlated events". У ваших правил 31/33/34 её нет.

Отсюда всё поведение из вашего лога: событие недоступности "ТРК сервер KMS" не совпало ни с одним из ваших правил (только со стандартными 2/58/86), поэтому не создались ни аварии, ни блокирующие таймеры. А SYS_NODE_UP при восстановлении не коррелируется никогда — правило 34 срабатывает и сразу шлёт "Node up", блокировать его нечем. У прокси всё работает, потому что его собственное событие недоступности не коррелированное.

Что сделать: откройте свойства правила 33 и включите "Accept correlated events". После этого при коротком обрыве прокси таймер будет создаваться и уведомление "Node up" от подчинённых узлов будет блокироваться — так же, как сейчас у прокси.

Один нюанс: при длительном обрыве прокси подчинённые узлы теперь тоже пришлют отложенные уведомления о недоступности (Critical MailAlarm через 10 минут и далее). Если они не нужны — учтите, что просто выключить эти действия нельзя: неактивное действие не создаёт таймер, и блокировка перестанет работать. В этом случае вместо уведомления назначьте отложенным действием с тем же ключом таймера какое-нибудь пустое действие.

Изменённые правила 27/28 по "Интернет резерв" теперь на основную схему не влияют.

Hi Tucson,

The agent is not actually unreachable — it accepts the connection, and the version mismatch is not the problem either. Your log shows what is going on:

- Each new connection completes the initial handshake (CMD_GET_NXCP_CAPS / CMD_NXCP_CAPS) — these control messages are processed directly by the session's network thread.
- The first real request, CMD_SET_SERVER_CAPABILITIES, is received but never answered. It is handed off to the agent's communication thread pool for processing, and that task never runs. The server waits 30 seconds for the response, reports "Request timeout", and closes the connection — you can see "Communication channel closed by peer" exactly 30 seconds after each connect.
- The "Session disconnected by watchdog" lines are not the cause: those are older sessions from previous failed attempts being cleaned up after the 120-second idle timeout (the timestamp deltas in those lines are all ~120 s).

This means all worker threads of the communication thread pool are stuck in requests that never complete. Typical causes are an ExternalParameter / ExternalMetric script that hangs, or a FileSystem.* metric blocking on a dead network mount (stale NFS/CIFS). Once all workers are blocked, the agent still accepts connections but cannot process any command — which matches your "works after restart, dies a few minutes later" pattern: after restart the pool is fresh, and it dies once the server's polls have handed it enough hanging requests. There is also an agent-side bug that prevents the pool from recovering in this situation — I have filed it as https://github.com/netxms/netxms/issues/3436.

To find what is blocking the threads on your side, please run on the agent host:

1. gdb -p $(pgrep nxagentd) --batch -ex 'thread apply all bt' > nxagentd-threads.txt and attach the output (install gdb if needed; eu-stack -p <pid> works too). The stacks of the threads named $COMM/WRK will show exactly where they are stuck.
2. nxget 127.0.0.1 Agent.Uptime — if this hangs, it confirms the thread pool is stuck.
3. df — if it hangs, you have a stale network mount, which is the common cause.

Also check whether your agent config has ExternalParameter / ExternalMetric entries, and whether those scripts can block (waiting on network, locks, prompts). Restarting the agent is a temporary workaround, but it will wedge again until the underlying hang is fixed.

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

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. Семь миллионов аварий за неделю. В логах видно почему: статус узла скачет NORMAL↔MINOR десятки раз в секунду (события SYS_NODE_MINOR / SYS_NODE_NORMAL с тегом NodeStatus), и на каждое такое событие создаётся авария. Это и есть причина постоянного роста базы и ошибок в alarm log. Покажите правило, которое создаёт аварии на события изменения статуса узла — скорее всего, его нужно убрать или сильно ограничить. И надо разбираться, почему статус так флапает — это лучше вынести в отдельную тему.

Thanks — the new data makes this clear. Everything on both switches is now discovered via LLDP, all six Eth-Trunk0 members and the 10GE4/0/47 keepalive resolve correctly in both directions, and the links on the down ports did not come back. Those were stale entries: NetXMS keeps unconfirmed peer information for Objects.Interfaces.PeerRetentionTime days (default 30) before removing it automatically, so your ~2-week-old entries were still within the retention window. You can lower that server configuration parameter if you want faster expiry.

The remaining MEth0/0/0 <-> 10GE2/0/1 "self" link is reported by the switches themselves, not invented by NetXMS. Your other links prove the two chassis advertise distinct LLDP chassis IDs, so the only way this entry can appear is that each switch sees its own LLDP frames back on those two ports. Check on the switch directly: display lldp neighbor interface 10ge 2/0/1 — if it lists the switch itself as neighbor, the loop is physical: either MEth0/0/0 is patched into 10GE2/0/1 on the same chassis (in-band management), or both ports connect to an unmanaged management switch that floods LLDP between them. To check from the NetXMS server side, please walk the full LLDP remote table on both switches and post the output here (or send them to me privately):

nxsnmpwalk -v 2c -c <community> 10.61.99.2 1.0.8802.1.1.2.1.4.1.1
nxsnmpwalk -v 2c -c <community> 10.61.99.3 1.0.8802.1.1.2.1.4.1.1

If the cabling is intentional, the displayed link is correct and can be ignored; disabling LLDP on MEth0/0/0 would also suppress it.

Thanks, issue registered: https://github.com/netxms/netxms/issues/3428

Thanks for the follow-up — you are right, 6.2.1 does not fully fix this.

The fix that went into 6.2.1 removed the visible flickering of the columns, but not the underlying cost. Grid views still re-measure and repack every column on each refresh cycle, and that is what you are seeing as constant repainting on the Data Collection and Interfaces tabs. On a node with many interfaces or DCIs a refresh can be triggered very often, so it never settles.

I've opened https://github.com/netxms/netxms/issues/3418 to track it. The proper fix is to repack columns only when the content actually changes shape (new columns, first data load, or when you ask for it), instead of on every refresh.

Until then you can avoid the problem by unchecking "Resize columns automatically" in the view menu of the affected view. The setting is remembered per view, and with it off the columns are no longer repacked on refresh.

The identical value on both switches is expected, not the fault. 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2 is hwMstpiBridgeID, and under V-STP the M-LAG pair presents itself as one logical bridge, so both chassis report the same bridge ID. In your case that ID (AC:5E:14:7F:89:01) is xA's own dot1dBaseBridgeAddress, which you can see in xA's Hardware Inventory tab.

NetXMS reads that OID specifically to handle this - see https://github.com/netxms/netxms/issues/3353, fixed in 6.2.0. Without it, STP discovery invents a link to the M-LAG peer on every downstream port. Which server version are you running? If it is older than 6.2.0, upgrade first and re-run a configuration poll plus a topology poll on both switches.

The peer-link and keepalive links in your screenshots look correct: the six Eth-Trunk0 members (40GE5/0/34-35, 40GE6/0/34-35, 40GE7/0/34-35) and 10GE4/0/47 all resolve to the right peer and match your diagram. Two other things do look wrong, and neither can come from STP discovery:

1. On both switches, MEth0/0/0 and 10GE2/0/1 list the switch itself as peer node, pointing at each other. STP discovery cannot produce a self-link - it skips a bridge that resolves to the local node.

2. 40GE6/0/6-9 on xA linked to 10GE4/0/42-45 on xB. These ports are DOWN/Disabled, and a down port has no forwarding or blocking STP state, so STP would not report them. They are also absent from your diagram.

Could you widen the Interfaces table and show the "Peer discovery protocol" column? It is cut off in both screenshots, and it is the one field that tells me which discovery source created these links (STP, LLDP, CDP, or FDB). Also confirm whether 40GE6/0/6-9 were ever cabled to xB - if they were, these may just be stale cached links.

TRUNCATE

Thanks for the detailed report.

The missing zone record is not what's breaking discovery. Object ID 4 is a built-in object: the server creates the Default zone in memory at every startup, and the code paths that use it (including active discovery) handle it correctly whether or not a row exists in zones / object_properties - the row only gets written once the zone is actually modified, e.g. when the first subnet is placed into it. So on a freshly initialized database the tables being empty is expected, and this is not specific to SQLite or to Windows.

The error message in the log is misleading, though, and the zone should be persisted at first startup instead of being re-created every time. I've opened https://github.com/netxms/netxms/issues/3410 for that.

For the discovery problem, which is a separate issue, please check the following:

1. Discovery type. In Server Configuration, check NetworkDiscovery.Type. If it is 0 (disabled), the "Scan" action will enqueue addresses but nothing will pick them up. For active scanning of configured ranges it must be 2 (active) or 3 (active and passive).

2. Enable discovery debug output. Either start the server with a higher debug level, or set it at runtime without a restart:

    nxadm -c "debug tag poll.discovery 6"

Then run the scan again and watch netxmsd.log. At level 6 you will see, per address, whether the host responded to the probe and - if it did - whether the potential node was rejected and why ("IP address already known at node ...", "rejected by discovery filter", etc.). Reset it afterwards with nxadm -c "debug tag poll.discovery off".

3. Probing method. By default active discovery only uses ICMP ping. If the target hosts do not answer ICMP, nothing will be found. Check NetworkDiscovery.ActiveDiscovery.EnableSNMPProbing and NetworkDiscovery.ActiveDiscovery.EnableTCPProbing, and make sure ICMP is not blocked between the server and the scanned range.

4. Discovery filter. If a filter script is configured, a responding host can still be dropped. The level 6 log above shows this explicitly.

5. Address ranges. Verify that the ranges under Network Discovery -> Active Discovery Targets are the ones you expect, and that they are IPv4 - IPv6 ranges are skipped by active discovery.

If you post the poll.discovery log from a scan run, I can tell you where it stops.

Thanks for the suggestion — I've opened an issue for it: https://github.com/netxms/netxms/issues/3409

At the moment all backup-related read operations (list of backups, latest backup, individual backup by ID) are gated only by "Read" access on the node, so anyone who can see the node can also pull the full device configuration with whatever it contains. Splitting that into a separate right for the backup list and another for viewing/exporting the actual content makes sense to me.

There are a few things to settle first — mainly what the default should be for existing installations, and the fact that the object access rights mask is nearly out of free bits — so I'll discuss it with the team before we implement anything. Feel free to add your thoughts to the issue.