NetXMS Support Forum

Итоги проверки:
- нет ли выше (правила 1–30) правила с флагом "Stop event processing", под которое попадает SYS_NODE_UNREACHABLE от этих узлов;

Не нашел такого.
Но нашел другие правила (NEW Telegram alarm when Интернет резерв is stop responding ICMP и NEW Telegram alarm when Интернет резерв is start responding ICMP). Я создавал его когда пытался отключить уведомления от подчиненных нод за прокси при пропадании интернета.
Убрал из секции cancel the following timers таймеры по этим нодам. Может они влияли еще. Теперь эти правила выглядят так (новые правила NEW Telegram alarm when Интернет резерв).

1. Понял. Учту.
2. Пока проверяю, отпишу. Вот характерный пример уведомлений. Выключил службу агента на прокси ноде ТРК сервер офис. Подождал 5 мин и включил службу агента на прокси ноде ТРК сервер офис. Итог уведомлений:
⌛ 18.Jul.2026 16:52:10
Severity Critical 🔴
ТРК сервер офис
👉 Node unreachable because of network failure

⌛ 18.Jul.2026 16:58:28
Severity Normal 🟢
ТРК сервер KMS
👉 Node up

⌛ 18.Jul.2026 16:58:38
Severity Normal 🟢
ТРК сервер офис
👉 Node up

Т.е. сначала приходит уведомление от ноды за прокси ТРК сервер KMS (хотя уведомления быть не должно так как там таймер 600 сек) а потом уже от прокси ноды ТРК сервер офис.

3. Понял. Создам отельную тему.

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.

более подробно один из интерфейсов VLAN 3385 к примеру

Quote from: Filipp Sudanov on July 10, 2026, 01:31:03 PMДа, так правильно. Ну или можно чуть более лаконично:

Code Select Expand

if (($node.name in ["ISW001", "ISW002", "ISW003"]) and ($1.name ~= "^VLAN.*"))
{
    return false;  // не создавать VLAN-интерфейсы
}
return true;


на одном их трех коммутаторов не срабатывает, и странным образом - добавляются все равно интерфейсы, но не все как ранее - а только последние некоторые, к примеру с 3385 по 3418 как на картинке.

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

Hi,

my setup involves several servers, all of which work fine.
However, recently, one of the agents has become unreachable.
After restarting the agent, the server could collect data, but the connection closed after around five minutes.
The agent logs show that the request from the server is accepted by the agent. What could be the issue here?

serverVersion: 6.1.1
agentVersion: 6.2.1
agentOS: Linux

The output from configuration poll:
[16.07.2026 10:31:44] **** Poll request sent to server ****
[16.07.2026 10:31:44] Poll request accepted, waiting for outstanding polling requests to complete...
[16.07.2026 10:31:44] Starting configuration of for node <nodename>
[16.07.2026 10:31:44] Checking node's capabilities...
[16.07.2026 10:31:44]    Checking NetXMS agent...
[16.07.2026 10:32:14]    Cannot connect to NetXMS agent (Request timeout)
[16.07.2026 10:32:14]    SNMP polling is disabled
[16.07.2026 10:32:14]    EtherNet/IP polling is disabled
[16.07.2026 10:32:14]    Modbus TCP polling is disabled
[16.07.2026 10:32:14] Capability check finished
[16.07.2026 10:32:14] Checking interface configuration...
[16.07.2026 10:32:14] Unable to get interface list from node
[16.07.2026 10:32:14] Interface configuration check finished
[16.07.2026 10:32:14] Checking node name
[16.07.2026 10:32:14] Node name cannot be interpreted as valid IP address, no need to resolve to host name
[16.07.2026 10:32:14] Updating general system hardware information
[16.07.2026 10:32:14] Processing template automatic apply rules
[16.07.2026 10:32:14] Processing container autobind rules
[16.07.2026 10:32:14] Processing cluster autobind rules
[16.07.2026 10:32:14] Finished configuration poll of node <nodename>
[16.07.2026 10:32:14] Node configuration was not changed after poll
[16.07.2026 10:32:14] **** Poll completed successfully ****
nxagentlog DebugLevel 8:
2026.07.16 08:20:21.884 *D* [comm               ] Incoming connection from <server-ip>
2026.07.16 08:20:21.884 *D* [comm               ] Connection from <server-ip> accepted
2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Session registered (control=true, master=true, upgrade=true)
2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Message dump:
  ** 000000 | 00 B6 50 20 00 00 00 10 00 00 00 00 00 00 00 00 | ..P ............
  ** code=0x00B6 (CMD_GET_NXCP_CAPS) version=5 flags=0x0020 id=0 size=16 numFields=0
  ** control message

2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Received control message CMD_GET_NXCP_CAPS
2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Using protocol version 5
2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Sending message CMD_NXCP_CAPS (ID 0; size 16; uncompressed)
2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Outgoing message dump:
  ** 000000 | 00 B7 50 20 00 00 00 10 00 00 00 00 05 00 00 00 | ..P ............
  ** code=0x00B7 (CMD_NXCP_CAPS) version=5 flags=0x0020 id=0 size=16 numFields=83886080
  ** control message

2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Message dump:
  ** 000000 | 01 34 50 00 00 00 00 38 00 00 00 01 00 00 00 05 | .4P....8........
  ** 000010 | 00 00 00 97 03 01 00 01 00 00 02 17 03 01 00 01 | ................
  ** 000020 | 00 00 02 18 03 01 00 01 00 00 02 3A 03 01 00 01 | ...........:....
  ** 000030 | 00 00 03 12 03 01 00 01                         | ........
  ** code=0x0134 (CMD_SET_SERVER_CAPABILITIES) version=5 flags=0x0000 id=1 size=56 numFields=5
  ** 000000: [   151] INT16       1
  ** 000008: [   535] INT16       1
  ** 000010: [   536] INT16       1
  ** 000018: [   570] INT16       1
  ** 000020: [   786] INT16       1

2026.07.16 08:20:21.884 *D* [comm.cs.4          ] Received message CMD_SET_SERVER_CAPABILITIES (1)
2026.07.16 08:20:22.224 *D* [dc                 ] DataCollector: sleeping for 60 seconds
2026.07.16 08:20:47.229 *D* [comm.cs.1          ] Session disconnected by watchdog (timestamp = 110222679040, now = 110222799452)
2026.07.16 08:20:47.229 *D* [comm.cs.1          ] CommSession::disconnect()
2026.07.16 08:20:51.885 *D* [comm.cs.4          ] Communication channel closed by peer
2026.07.16 08:20:51.921 *D* [comm               ] Incoming connection from <server-ip>
2026.07.16 08:20:51.921 *D* [comm               ] Connection from <server-ip> accepted
2026.07.16 08:20:51.921 *D* [comm.cs.5          ] Session registered (control=true, master=true, upgrade=true)
2026.07.16 08:20:51.921 *D* [comm.cs.5          ] Message dump:
  ** 000000 | 00 B6 50 20 00 00 00 10 00 00 00 00 00 00 00 00 | ..P ............
  ** code=0x00B6 (CMD_GET_NXCP_CAPS) version=5 flags=0x0020 id=0 size=16 numFields=0
  ** control message

2026.07.16 08:20:51.921 *D* [comm.cs.5          ] Received control message CMD_GET_NXCP_CAPS
2026.07.16 08:20:51.921 *D* [comm.cs.5          ] Using protocol version 5
2026.07.16 08:20:51.921 *D* [comm.cs.5          ] Sending message CMD_NXCP_CAPS (ID 0; size 16; uncompressed)
2026.07.16 08:20:51.922 *D* [comm.cs.5          ] Outgoing message dump:
  ** 000000 | 00 B7 50 20 00 00 00 10 00 00 00 00 05 00 00 00 | ..P ............
  ** code=0x00B7 (CMD_NXCP_CAPS) version=5 flags=0x0020 id=0 size=16 numFields=83886080
  ** control message

2026.07.16 08:20:51.922 *D* [comm.cs.5          ] Message dump:
  ** 000000 | 01 34 50 00 00 00 00 38 00 00 00 01 00 00 00 05 | .4P....8........
  ** 000010 | 00 00 00 97 03 01 00 01 00 00 02 17 03 01 00 01 | ................
  ** 000020 | 00 00 02 18 03 01 00 01 00 00 02 3A 03 01 00 01 | ...........:....
  ** 000030 | 00 00 03 12 03 01 00 01                         | ........
  ** code=0x0134 (CMD_SET_SERVER_CAPABILITIES) version=5 flags=0x0000 id=1 size=56 numFields=5
  ** 000000: [   151] INT16       1
  ** 000008: [   535] INT16       1
  ** 000010: [   536] INT16       1
  ** 000018: [   570] INT16       1
  ** 000020: [   786] INT16       1

2026.07.16 08:20:51.922 *D* [comm.cs.5          ] Received message CMD_SET_SERVER_CAPABILITIES (1)
2026.07.16 08:20:52.229 *D* [comm.cs.2          ] Session disconnected by watchdog (timestamp = 110222679791, now = 110222804453)
2026.07.16 08:20:52.229 *D* [comm.cs.2          ] CommSession::disconnect()
2026.07.16 08:20:57.229 *D* [comm.cs.3          ] Session disconnected by watchdog (timestamp = 110222687458, now = 110222809453)
2026.07.16 08:20:57.230 *D* [comm.cs.3          ] CommSession::disconnect()
2026.07.16 08:21:21.922 *D* [comm.cs.5          ] Communication channel closed by peer
2026.07.16 08:21:22.224 *D* [dc                 ] DataCollector: sleeping for 60 seconds
2026.07.16 08:21:56.957 *D* [comm               ] Incoming connection from <server-ip>
2026.07.16 08:21:56.957 *D* [comm               ] Connection from <server-ip> accepted
2026.07.16 08:21:56.957 *D* [comm.cs.6          ] Session registered (control=true, master=true, upgrade=true)
Kind regards

Отправляю скришоты alarm log с прокси ноды и ноды за прокси (подчиненной).
Что еще можно проверить?