NetXMS Support Forum

Hi Alex,

Thanks for the detailed explanation. The problem was caused by an offline network mount.
After disabling the metric on the server and restarting the agent, it runs without any issues.

One weird thing that happened while troubleshooting was that the command
gdb -p $(pgrep nxagentd) --batch -ex 'thread apply all bt' > nxagentd-threads.txt didn't generate thread information; it only displayed "[New LWP <process ID>]" lines.

Is there any update on this is it on the roadmap I would love to have single sign on from our Azure AD

Is there any update on the release of this the test flight application looked very promising

Прикладываю лог событий с нод ТРК сервер офис и Смарт ****** сервер 1С.
Может стоит включить в правило 31 Mail alarm when node connected by tunnel / proxy node is down 300 sec (Уведомление по почте если нода подключенная через тунель / прокси нода недоступна в течении 300 сек)
событие SYS_NODE_UNREACHABLE?

В дополнение ко всему пришло сегодня ночью одинокое уведомление
⌛ 27.Jul.2026 03:33:03
Severity Normal 🟢
Смарт ******* сервер 1C
👉 Node up

Уведомления о недоступности этой ноды не было. Эта нода включена в шаблон Node by tunnel epp. Нода не является прокси но подключена через тунель

Что-то не так работает как ожидалось.
Было отключение интернета в филиале с 17.26 до 18.26 26.07.2026.
Пришло уведомление об отключении интернета и уведомление о недоступности ноды ТРК KMS (это нода за прокси). При этом уведомление о недоступности прокси ноды ТРК сервер офис не приходило.
Когда интернет в филиале включили то пришли уведомлении о включении интернета, доступности ноды ТРК сервер офис (прокси нода), доступности ноды ТРК KMS (нода за прокси).
Как сделать чтобы при отключении интернета приходило уведомление и о недоступности прокси ноды?

Вот так выглядели уведомления:
⌛ 26.Jul.2026 17:26:27
Severity Major 🔴
ТРК интернет
👉 Node is unreachable by ICMP

===========================>>> Тут не хватает уведомления о недоступности прокси ноды ТРК сервер офис

⌛ 26.Jul.2026 17:26:02
Severity Critical 🔴
ТРК сервер KMS
👉 Node unreachable because of network failure

⌛ 26.Jul.2026 18:26:57
Severity Normal 🟢
ТРК интернет Роктел
👉 Node started responding to ICMP

⌛ 26.Jul.2026 18:27:15
Severity Normal 🟢
ТРК сервер офис
👉 Node up

⌛ 26.Jul.2026 18:27:34
Severity Normal 🟢
ТРК сервер KMS
👉 Node up

Одно замечание на будущее: системное SYS_ICMP_UNREACHABLE при падении ноды коррелируется к её SYS_NODE_DOWN, а ваш кастомный icmp unreachable — нет. Если нода, на которой висит этот DCI, упадёт целиком, придут оба уведомления — и о ноде, и об интернете. Для порогов с кастомными событиями корреляция такие следствия не гасит.
--------------
Это правило висит на ноде "Интернет название филиала". Завел отдельную ноду которую так обозвал. И так с каждым внешним ip адресом филиала.
Прокси нода и другие сервера выделены в отдельные ноды. Цель: получение отдельных уведомлений о недоступности интернета в филиалах и серверов в этих филиалах. Есть филиалы с основным и резервным интернетом, есть те у кого проблемы с электропитанием.

Hi,

Most likely the virtual interfaces are actually present as objects, and what's missing is only the DCIs for them - these are two separate mechanisms. Here's what's actually happening:

NetXMS builds the interface list from the standard ifTable and creates interface objects for everything the device reports - VLAN, PPPoE, bridges and tunnels included, there is no filtering by type at that stage. So after a configuration poll they all should be visible in the Interfaces view under the node - I do believe they are there on your system? If some are genuinely missing even after configuration poll, that would mean RouterOS is not exposing them over SNMP, but that would be unusual.

What filters them out is the Interface Traffic template itself. Its DCIs are created by instance discovery, and the filter script in the prototype DCIs only accepts interfaces with ifType 6, 7 or 22 (ethernet-like types). VLAN (ifType 135), PPP/PPPoE (23), tunnels (131), bridges (209) are all rejected by that check. The filter also skips loopbacks, interfaces whose expected state is not UP, and interfaces with speed at or below 20 Mbit/s.

You can see it happening: run Poll -> Instance discovery on the node and look at the poller output - there will be a "skipped - interface type" line for every virtual interface.

To include them, open the template under Templates -> Interface traffic, edit the instance discovery filter script in the prototype DCIs and extend the interfaceTypes array at the top with the types your virtual interfaces report:

interfaceTypes = [6, 7, 22, 23, 131, 135, 209];
Actual ifType of every interface is shown on the interface object's Overview tab, so check there which values you need. Note: with default server configuration (Server.ImportConfigurationOnStartup = 1) your edits to this template survive server upgrades - stock templates are not overwritten on import.

For CPU / temperature / voltage on MikroTik you don't need to hunt for OIDs manually:

• Health metrics - create DCI with origin "Network device driver". For MikroTik nodes the driver reads the RouterOS health gauge table and offers every gauge the particular model exposes (cpu-temperature, board-temperature, voltage, fan speeds, etc.) by name in the metric selection dialog. Values come exactly as the device reports them, so check the scale and add a transformation script if needed.
• CPU load - standard SNMP DCI on 1.3.6.1.2.1.25.3.3.1.2 (hrProcessorLoad from HOST-RESOURCES MIB, one row per core).

Put these DCIs into your own template and let it apply automatically to all RouterOS devices with auto-apply filter script:

return $node.driver == "MIKROTIK";
- same idea as the custom attribute you already use for interface traffic, just keyed on the driver instead.

Да, подход верный. Ваши icmp unreachable / icmp ok — кастомные события, а для кастомных событий корреляция существует ровно в одном случае: когда нода-источник в режиме обслуживания (там коррелируются вообще все её события). К падению ноды, прокси или коммутатора сервер их никогда не привязывает — это делается только для фиксированного списка системных событий (SYS_ICMP_UNREACHABLE, SYS_INTERFACE_DOWN и т.д.).

Поэтому пара 25/26 — тот же случай, что 31/32, и логика распределяется так же:

• Правило 25 без флага: в нормальной работе события некоррелированные, правило срабатывает всегда. В maintenance они становятся коррелированными, и правило само их пропустит — скрипт с проверкой не нужен.
• Правило 26 с флагом: нужен ровно для сценария «интернет упал (аларм создан, таймеры 8h/1d/3d заведены) → ноду перевели в обслуживание → интернет восстановился». Без флага icmp ok будет пропущено, аларм останется висеть, и через 8 часов придёт письмо о недоступности уже работающего интернета.

Одно замечание на будущее: системное SYS_ICMP_UNREACHABLE при падении ноды коррелируется к её SYS_NODE_DOWN, а ваш кастомный icmp unreachable — нет. Если нода, на которой висит этот DCI, упадёт целиком, придут оба уведомления — и о ноде, и об интернете. Для порогов с кастомными событиями корреляция такие следствия не гасит.

По шторм-детектору: вы его не пропустили — он не сработал, потому что выключен по умолчанию (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 эти изменения молча не применились, остались свежие дефолтные версии.