NetXMS Support Forum

Quote from: Argonauts on December 16, 2025, 10:10:31 AMПоставил smartmontools 7.5 релиз
Metric PhysicalDisk.SmartAttr(/dev/sda, Raw_Read_Error_Rate) - Dci значений никаких не отдает, error в поле Value
PhysicalDisk.Devices - Table, так же не отдает ничего
PhysicalDisk.SmartStatus(/dev/sda) - Dci, так же не отдает ничего
smartctl --scan отдает
/dev/sda -d ata # /dev/sda, ATA device
/dev/sdb -d ata # /dev/sdb, ATA device
В системе стоит 2шт Sata SSD
smartctl -H /dev/sda вполне отрабатывает
SMART overall-health self-assessment test result: PASSED
Как и запросы конкретных параметром из shell на самой машине проходят нормально

Скрин DCI


Или мб в конфиге агента нужно прописать дополнительно что-то?

Разобрались? Тоже хочу прикрутить сбор этих параметров.

а это время в 5 минут - оно в свойствах экшна настроено?

Да.

Экшн при потере контакта
https://drive.google.com/file/d/1o4BwNM8HnuWaRQPScepYWZYPvQbMOYbo/view?usp=sharing

Экшн при возобновлении контакта
https://drive.google.com/file/d/1qC6ov1e5h5ORca-rJ1U9YKdXMS5TAXgm/view?usp=sharing

какая точно версия NetXMS?

5.2.6

можете показать для такой ситуации event log, отфильтрованный по двум нодам - прокси и какая-нибудь одна нода, которая за этой прокси? По идее события автоматически должны кореллироваться на SYS_NODE_DOWN этой прокси, но возможно что-то поломано.

event log прокси нода
https://drive.google.com/file/d/1At9jEzyr816qNNciSHviE1Blblwqq1-d/view?usp=sharing

event log нода
https://drive.google.com/file/d/1oot7rKzNgLHPh-uonKD-T0MYRs5Tr_5t/view?usp=sharing


Получил скриншоты следующим образом: остановил службу netxms agent на прокси ноде на 1 минуту. Потом включил службу netxms agent на прокси ноде. От прокси ноды уведомление не пришло зато пришло от подчиненной ноды что она  появилась в сети.

Здравствуйте,
Использую в работе агенты с включенным режимом прокси для мониторинга устройств в удаленных офисах. При этом если теряется контакт с прокси нодой на более чем 5 мин (время настроено через таймер) то уведомление приходит только от прокси ноды (тут все как и ожидалось). Когда контакт с прокси нодой восстанавливается то уведомления приходят и от прокси ноды и от подчиненных нод (тоже как и ожидалось).
Проблема появляется когда контакт с прокси нодой теряется кратковременно (т.е. контакт потерян и восстановлен в пределах 5 мин). В таком случае уведомление от прокси ноды не приходит (как и ожидалось) но зато приходят уведомления от всех подчиненных нод что они появились в сети. И так каждый раз при кратковременной потери контакта с прокси нодой.
Как этого можно избежать?

Вопрос снимается. Почитал про джиттер пинга и все стало на свои места.
Если кому понадобится вот список хороших статей на эту тему:
Общая статья
https://noping.com/ru/blog/jitter-vs-latency-ping
Хабр
https://habr.com/ru/companies/pixonic/articles/559780/
Самая детальная статья
https://ssl-team.com/blog/jitter-chto-eto-takoe-pri-proverke-skorosti-interneta/?ysclid=mbi9zegdz7965811099
Программа pingplotter
https://lanta-net.ru/podderzhka/rekomendaczii-po-ispolzovaniyu-programmyi-pingplotter.html?ysclid=mbiasec3yn780880519

Здравствуйте,
Подскажите логику dci параметра джиттер пинга.
Задача: настроить dci что будет уведомлять меня если есть обрывы пинга до wan ip роутера в филиале (именно обрывы а не ситуация когда wan ip недоступен полностью).
Сейчас настроил субагент на сервере netxms, прописал таргет (wan ip роутера), собираю статистику по среднему и максимальному времени пинга, потере пакетов.

Пытаюсь обновить агент:
root@ubuntusrv:~$ sha256sum netxms-release-latest.deb
18db187d42946041ff5edfccd53982f309747420bf1374432713ace0029e34fa  netxms-release-latest.deb
sad@ubuntusrv:~$ sudo dpkg -i netxms-release-latest.deb
(Чтение базы данных ... на данный момент установлено 119887 файлов и каталогов.)
Подготовка к распаковке netxms-release-latest.deb ...
Распаковывается netxms-release (1.12) на замену (1.12) ...
Настраивается пакет netxms-release (1.12) ...
root @ubuntusrv:~$ sudo apt-get update
Сущ:2 http://old-releases.ubuntu.com/ubuntu impish InRelease
Пол:1 https://packages.netxms.org/ubuntu impish InRelease [19,5 kB]
Сущ:3 http://old-releases.ubuntu.com/ubuntu impish-updates InRelease   
Сущ:4 http://old-releases.ubuntu.com/ubuntu impish-backports InRelease
Сущ:5 http://old-releases.ubuntu.com/ubuntu impish-security InRelease
Получено 19,5 kB за 1с (19,8 kB/s)       
Чтение списков пакетов... Готово

И агент остается той же версии)

При попытке обновления агента через консоль долго висит и потом выдает ошибку: Cannot start package deployment: Reques timed out

1 нода Ubuntu 22.04.5 LTS
2 нода Ubuntu 21.10

Здравствуйте 
Подскажите команду обновления агента на ubuntu.
Как ни пробую выдаёт что пакет уже установлен и обновлений не найдено. 

Возможно ли обновление агентов на машинах с ubuntu из меню Package Manager? 

Добавил все ноды на какие требуются уведомления в правило event processing policy как в первом сообщении. Протестировал... и снова получил уведомление когда нода стала доступна менее чем через 5 мин.

Тут важный момент: я использую прокси-агенты.
К примеру указанный сервер Мода сервер AD является прокси-агентом. Нода Мода сервер 1С подключена к серверу netxms через прокси-агент Мода сервер AD.
Так вот при пропадании интернета менее 5 мин и его возобновлении я получаю уведомление о том что сервер Мода сервер 1с в сети. При этом уведомления от ноды Мода сервер AD не поступает как и положено.

Я проверил журнал событий ноды Мода сервер 1с и обнаружил что при пропадании интернета на этой ноде формируется событие SYS_NODE_UNREACHABLE. При возобновлении интернета формируется событие SYS_AGENT_OK. То есть для этой ноды что связана с сервером netxms через прокси-агент не было события
SYS_AGENT_UNREACHABLE а при возобновлении связи было событие  SYS_AGENT_OK. Поэтому netxms и уведомляет при кратковременном обрыве соединения (до 5 мин) что эта нода стала доступна.

Вот думаю что с этим делать. Пока из мыслей сделать правила event processing policy для нод что соединяются с сервером напрямую и отдельные правила для нод что соединяются через прокси-агенты.

Долго я конечно отписываюсь)
При копировании существующего правила о недоступности нод система сначала призадумалась на пару секунд (была видна загрузка процессора), а потом все же скопировала правило. При попытке зайти в скопированное правило для редактирования выдается ошибка.


Поэтому создал с нуля два правила по конфигурации как в первом сообщении с применением для одной ноды. Эту ноду исключил из всех остальных правил. Протестировал - работает как надо (Скриншот правила прилагаю).

Скоро в это правило добавлю остальные ноды-контейнеры и посмотрю как будет работать

Создам 2 новых правила для тестовой ноды и попробую еще раз. Отпишу.

Исходя из своих экспериментов я сделал вывод что настройка timer cancellation отменяет таймер сразу при наступлении события sys_agent_ok.

Я неверно поставил вопрос.

Конечная цель - настроить правила EPP таким образом чтобы выстроить следующую цепочку:
1. Нода недоступна - запускаем таймер на 5 мин. Уведомление при этом не приходит.
2. Если нода стала доступной менее чем за 5 мин то уведомление не приходит. Если время недоступности ноды составляет более 5 мин то приходит уведомление что нода недоступна.
3. Когда нода поднимается после 5 и более мин недоступности приходит уведомление что нода поднялась.

Пример: на объекте пропал интернет. Через 5 мин пришло уведомление что нода недоступна. Когда интернет починили пришло уведомление что нода поднялась.

Пункты 1-2 смог реализовать. Как прикрутить пункт 3 не знаю.

Есть идеи как настроить такую цепочку правил EPP?

Кажется нашел в чем проблема. Проверяю.

Создавая правила я старался не изменять те правила что были по дефолту а создавать свои.
Т.е. программа увидела что нода недоступна и записала это в журнал (используя правило 1 что настроено по дефолту). Далее если нода недоступна более 5 мин то тогда уже уведомление в телеграм.

На объекте где расположена одна из нод часто отключался интернет (провайдер вел работы в течении нескольких месяцев). Вот для этой ноды сделал отдельное правило с уведомлением в 2 мин.