NetXMS Support Forum

Hi,

No problems, and running pvesh from the agent works fine. On the second question the choice isn't quite what it looks like though, because with NetXMS the REST API route is itself an agent feature.

pvesh works from the agent for a reason worth knowing about: it invokes API functions directly without going through the REST/HTTPS server, and it requires root. The packaged agent runs as root - the systemd unit does not drop privileges, and the agent changes uid only if you pass -u/-g or set UserId/GroupId in nxagentd.conf. So it works with no extra setup, which also means anyone who can add a DCI can make the agent fork a root command on the hypervisor. Worth deciding that deliberately rather than finding it out later.

What will actually bite you is process spawning. ExternalParameter (ExternalMetric in current naming) forks a process per metric per poll, and pvesh is a Perl program that loads the PVE API modules on every invocation. One metric per guest on a 60 second interval turns into a continuous stream of interpreter startups on the host. The default execution timeout is 5 seconds (ExecTimeout, or ExternalMetricTimeout for these specifically), and a slow pvesh call will hit it and get killed.

Use ExternalDataProvider instead - added in 5.2.0. It runs the command once per polling interval, caches the output, and serves any number of metrics out of the cached document with jq queries, evaluated inside the agent so there is no jq binary to install:

[ExternalDataProvider/PVE]
Command = ["/usr/bin/pvesh", "get", "/cluster/resources", "--type", "vm", "--output-format", "json"]
PollingInterval = 60
Timeout = 30000

[ExternalDataProvider/PVE/Metrics]
PVE.Guest.Status(*) = .[] | select(.vmid == $1) | .status
PVE.Guest.CPU(*) = .[] | select(.vmid == $1) | .cpu
PVE.Guest.CPU(*).dataType = float
PVE.Guest.Memory(*) = .[] | select(.vmid == $1) | .mem
PVE.Guest.Memory(*).dataType = uint64

[ExternalDataProvider/PVE/Lists]
PVE.Guests = .[] | .vmid

That is one pvesh call a minute for the whole cluster no matter how many DCIs you build on top, and PVE.Guests gives you instance discovery over vmid. Two details: Timeout here is in milliseconds, and metrics with parameters ($1) need agent 6.0 or newer - on 5.2 define each metric with a fixed query instead.

On agent versus REST: there is no version of the REST route that doesn't involve an agent. Web service DCIs are executed by an agent acting as web service proxy - the server never makes the HTTP request itself. If the node has no web service proxy configured it falls back to the zone proxy, and finally to the management server node, so "just using the REST API" in practice means "the server's own agent makes the call". The choice is which agent and where it sits, not whether there is one.

Consequences:

• Responses are cached per URL for the retention time set on the web service definition, so every DCI reading out of the same document costs one HTTP request. Against /cluster/resources that is a single call per interval covering every guest in the cluster.
• The extraction is identical either way - web service DCIs and ExternalDataProvider share the same jq-based extractor, so the queries you write don't change with the route.
• Only an agent on the PVE host can reach 8006 on localhost, which matters if that port isn't open to the server. Poll from an agent elsewhere and you install nothing on the hypervisor at all.

So the real trade is narrow. pvesh saves you managing an API token, at the price of forking a root-privileged Perl process on the hypervisor. The web service route costs you a token and gives you a read-only credential in exchange (PVEAuditor is enough), one HTTP call per interval, and the freedom to poll from an agent that isn't on the PVE host. I'd take the REST API as the default and keep pvesh for anything the HTTP API doesn't expose.

One thing has changed since my post above. The OTLP route I said didn't work now does - the receiver accepted protobuf only, which is why PVE 9's OpenTelemetry metric server couldn't reach it, and that is fixed in 6.2.3 (https://github.com/netxms/netxms/issues/3482), released on 9 August. On 6.2.3 or later you can point Datacenter - Metric Server - OpenTelemetry straight at the NetXMS web API and have PVE push guest metrics on its own: no collector in between, no polling, and no agent on the host. It needs an auth token passed through the otel-headers option, and the receiver is loaded as a server module (Module = otlp in netxmsd.conf). None of the ingestion side is documented yet - https://github.com/netxms/netxms-doc/issues/67 covers that.

Not implemented at the moment - the Objects tab covers the Infrastructure tree only. Noted as a feature request, no date on it.

Hi Alex,

Thanks for the update what I mean buy the Network view is currently you have Objects which replicate the Infrastructure view in the GUI it would be good to have Networks as well so you can browse through the list of Zones, Subnets and devices like you can in the GUI

Just curious would installing the netxms agent cause any issues if we want to run api commands localty via pvesh from the agent and create DCI's from that. Not sure if the agent has any advantage over just using the rest api.


Thanks

Это не регрессия сборки 6.2.3. Линковщик берёт libnxdb не из дерева сборки, а из /usr/local/lib — ту, что осталась от установленной 6.2.2. Путь в самой ошибке это и показывает: /usr/local/lib/libnxdb.so.62, а не /home/admin/netxms-6.2.3/src/db/libnxdb/.libs/.

Самое простое — запустить make install вместо make. Установка рекурсивная: каждый каталог сначала собирается и тут же устанавливается, и src/db проходит задолго до src/server/tools. К моменту линковки nddload в /usr/local/lib лежит уже libnxdb от 6.2.3, и подстановка срабатывает правильно. Отдельный make ломается именно потому, что ничего не устанавливает и файл от 6.2.2 остаётся на месте до самого конца.

Что происходит:

В 6.2.3 бэкпортнут фикс https://github.com/netxms/netxms/issues/3483 — case folding для Unicode стал locale-independent и считается по таблицам Unicode, а не через towupper/towlower из libc. Вместе с этим из libnetxms убраны собственные wcsupr/wcslwr, вместо них nx_wcsupr/nx_wcslwr. Сами wcsupr/wcslwr — расширения MSVC, ни в C, ни в POSIX их нет и в glibc не было никогда, поэтому NetXMS всегда собирал свои реализации, а libnxdb на них ссылалась. В 6.2.3 libnetxms их больше не экспортирует.

soname у всей ветки 6.2.x один — .so.62, он считается из major.minor и от patch-версии не зависит. Поэтому файл от 6.2.2 называется ровно так же, как собираемый сейчас, и подменяет его молча. При сборке 6.1.2 и 6.2.2 набор экспортируемых символов совпадал, и подмена ни на что не влияла — поэтому вы её не видели. В 6.2.3 символы исчезли, и старая libnxdb перестала линковаться.

Откуда в поиске берётся /usr/local/lib: configure добавляет -L/usr/local/lib, если такой каталог существует. Он существует, потому что там установлена 6.2.2.

Почему упало именно на nddload, хотя netxmsd собрался: netxmsd передаёт libnxdb явным путём в дереве сборки. У nddload и остальных утилит из src/server/tools libnxdb в списке нет — она приходит только как зависимость libnxsrv, и её приходится искать, а поиск попадает в /usr/local/lib. nddload — первая программа в этом каталоге по порядку сборки. Сами библиотеки собрались нормально потому, что shared library линкуется с неразрешёнными символами, а программа — нет.

Порядок:

systemctl stop netxmsd                 # имя юнита зависит от сборки
cd /home/admin/netxms-6.2.3
make install
ldconfig
nxdbmgr upgrade                        # 6.2.3 это схема 62.38, сейчас база на 62.35
systemctl start netxmsd

Важная деталь: make install перезаписывает установленную 6.2.2 по ходу дела, а не одним шагом в конце. Поэтому сервер лучше остановить заранее, и если сборка упадёт где-то дальше, установка останется наполовину обновлённой. Если хочется сначала довести до конца обычный make, старые библиотеки придётся убрать из /usr/local/lib руками — libnetxms.*, libnx*.*, libethernetip.*, libipfix.*

Проверить, что дело именно в этом, если понадобится:

nm -D -u /usr/local/lib/libnxdb.so.62 | c++filt | grep -E 'wcsupr|wcslwr'
nm -D -u /home/admin/netxms-6.2.3/src/db/libnxdb/.libs/libnxdb.so.62 | c++filt | grep -E 'wcsupr|wcslwr'

У установленной сейчас должно быть __wcsupr(wchar_t*) и wcslwr(wchar_t*), у свежесобранной — nx_wcsupr(wchar_t*) и nx_wcslwr(wchar_t*).

Каталог /usr/local/lib/netxms (dbdrv, ndd, субагенты) трогать не нужно, make install перезапишет его содержимое. Если в нём остались модули от версий старше 6.2.2, которых в 6.2.3 уже нет, они там и останутся, и при загрузке будут падать с такой же ошибкой про неразрешённый символ — уже в рантайме, в лог сервера.

На то, что утилиты из src/server/tools линкуются с установленной библиотекой вместо собранной, завёл тикет: https://github.com/netxms/netxms/issues/3548

1. I've added support for long-living tokens in build 36. Optionally you can enable Face ID, if you want to. You need server 6.2.2. or newer for that to work properly.
2. What do you mean by network view?
3. Yes, since webapi itself is purely http-only, you need any kind of reverse proxy (reproxy, nginx, etc.), which will do SSL offloading.

Добрый день!

Спасибо за помощь, помогло! Выкладываю ниже вывод.

1. Upgrade до 6.2.2

[root@AltTEST data]# psql -U postgres -X -d netxms_db -c "SELECT extname, extversion FROM pg_extension WHERE extname='timescaledb'"
Password for user postgres:
ERROR:  could not access file "timescaledb-2.26.3": No such file or directory


[root@AltTEST data]# ls $(pg_config --pkglibdir)/timescaledb*
/usr/lib64/pgsql/timescaledb-2.27.2.so  /usr/lib64/pgsql/timescaledb.so  /usr/lib64/pgsql/timescaledb-tsl-2.27.2.so


[root@AltTEST data]# systemctl restart postgresql
[root@AltTEST data]# psql -X -d netxms_db -U postgres
Password for user postgres:
psql (18.4)
Type "help" for help.

netxms_db=# ALTER EXTENSION timescaledb UPDATE;
ALTER EXTENSION
netxms_db=# \dx timescaledb
                                                       List of installed extensions
    Name     | Version | Default version | Schema |                                      Description
-------------+---------+-----------------+--------+---------------------------------------------------------------------------------------
 timescaledb | 2.27.2  | 2.27.2          | public | Enables scalable inserts and complex queries for time-series data (Community Edition)
(1 row)

netxms_db=#


[root@AltTEST data]# nxdbmgr upgrade
NetXMS Database Manager Version 6.2.2 Build 6.2-614-gfd28d43d5e

INFO: Server module WEBAPI skipped
Upgrading database...
Upgrading from version 62.1 to 62.2
Upgrading from version 62.2 to 62.3
Upgrading from version 62.3 to 62.4
Upgrading from version 62.4 to 62.5
Upgrading from version 62.5 to 62.6
Upgrading from version 62.6 to 62.7
Upgrading from version 62.7 to 62.8
Upgrading from version 62.8 to 62.9
Upgrading from version 62.9 to 62.10
Upgrading from version 62.10 to 62.11
Upgrading from version 62.11 to 62.12
Upgrading from version 62.12 to 62.13
Upgrading from version 62.13 to 62.14
Upgrading from version 62.14 to 62.15
Upgrading from version 62.15 to 62.16
Upgrading from version 62.16 to 62.17
Upgrading from version 62.17 to 62.18
Upgrading from version 62.18 to 62.19
Upgrading from version 62.19 to 62.20
WARNING:  column type "character varying" used for "service_name" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "scope_name" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "severity_text" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "trace_id" does not follow best practices
HINT:  Use datatype TEXT instead.
WARNING:  column type "character varying" used for "span_id" does not follow best practices
HINT:  Use datatype TEXT instead.
Upgrading from version 62.20 to 62.21
Upgrading from version 62.21 to 62.22
Upgrading from version 62.22 to 62.23
Upgrading from version 62.23 to 62.24
Upgrading from version 62.24 to 62.25
Upgrading from version 62.25 to 62.26
Upgrading from version 62.26 to 62.27
Upgrading from version 62.27 to 62.28
Upgrading from version 62.28 to 62.29
Upgrading from version 62.29 to 62.30
Upgrading from version 62.30 to 62.31
Upgrading from version 62.31 to 62.32
Upgrading from version 62.32 to 62.33
Upgrading from version 62.33 to 62.34
Upgrading from version 62.34 to 62.35
Database upgrade succeeded

После чего всё запустилось и работает! Ещё раз спасибо!

2. Обновление до 6.2.3

Собрать не удалось, в какой то момент при сборке появляется ошибка. Вывод консольный ниже:

make[5]: Leaving directory '/home/admin/netxms-6.2.3/src/server/tools/scripts'
make[5]: Entering directory '/home/admin/netxms-6.2.3/src/server/tools'
  CXX      nddload/nddload-nddload.o
  CXXLD    nddload/nddload
ld: /usr/local/lib/libnxdb.so.62: undefined reference to `__wcsupr(wchar_t*)'
ld: /usr/local/lib/libnxdb.so.62: undefined reference to `wcslwr(wchar_t*)'
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:691: nddload/nddload] Error 1
make[5]: Leaving directory '/home/admin/netxms-6.2.3/src/server/tools'
make[4]: *** [Makefile:1010: all-recursive] Error 1
make[4]: Leaving directory '/home/admin/netxms-6.2.3/src/server/tools'
make[3]: *** [Makefile:491: all-recursive] Error 1
make[3]: Leaving directory '/home/admin/netxms-6.2.3/src/server'
make[2]: *** [Makefile:494: all-recursive] Error 1
make[2]: Leaving directory '/home/admin/netxms-6.2.3/src'
make[1]: *** [Makefile:546: all-recursive] Error 1
make[1]: Leaving directory '/home/admin/netxms-6.2.3'
make: *** [Makefile:478: all] Error 2


До этого на том же сервере собирал 6.1.2 и 6.2.2 - не было проблем. 6.2.2 собралось, успешно обновилось и работает.

На первый взгляд работает. Еще проверяю. Вчера обновлял сервер до 6.2.3
Пришло только 1 уведомление в режиме обслуживания:

⌛ 09.Aug.2026 17:01:58
❗ ❗ Service is still unreachable for 1 day
Severity Critical 🟡
***** компьютер архивов
👉 Node unreachable because of network failure

ну это не страшно

Hi Alex,

Thanks for posting the update including MFA this is working well a couple of observations / Questions.

1. Once authenticated could the app save the login and then use Face ID on the phone to unlock?
2. Are there plans to include the Network view?
3. Currently I am only using it internally but I want to expose it externally I was going to use a reverse proxy to handle SSL is this the best way ?

Добрый день,

6.2.2 не требует TimescaleDB 2.26.3 — апгрейд вообще не привязан ни к какой конкретной версии расширения. Единственное требование во всей ветке 62.x — TimescaleDB не ниже 2.10, оно проверяется на более позднем шаге, где создаются continuous aggregates, и 2.27.2 его закрывает. Ошибка приходит не из NetXMS: PostgreSQL пытается загрузить библиотеку расширения timescaledb версии 2.26.3, потому что именно эта версия записана в каталоге базы, а на диске после обновления пакета осталась только 2.27.2. Пакет обновили, а расширение внутри базы — нет.

Почему упало именно здесь: ALTER TABLE object_tools ADD applicable_classes — первый DDL за весь апгрейд. Шаги с 61.36 до 62.1 только пишут строки в metadata и config, а на DDL PostgreSQL обязан загрузить код расширения, потому что timescaledb вешает на DDL свои event triggers. Сам шаг 62.1 → 62.2 к TimescaleDB отношения не имеет, object_tools — обычная таблица, не hypertable.

Сначала стоит убедиться, что картина именно такая:

psql -X -d netxms -c "SELECT extname, extversion FROM pg_extension WHERE extname='timescaledb'"
ls $(pg_config --pkglibdir)/timescaledb*

Если extversion показывает 2.26.3, а на диске лежит только timescaledb-2.27.2.so — причина в этом.

Порядок действий:

systemctl restart postgresql          # имя юнита зависит от сборки пакета
psql -X -d netxms                     # -X обязателен
ALTER EXTENSION timescaledb UPDATE;   # первой же командой в сессии
\dx timescaledb

Два момента, из-за которых это часто не проходит с первого раза: ALTER EXTENSION должен быть первой командой в сессии — после любого другого запроса библиотека старой версии уже пытается загрузиться, и апдейт падает с той же ошибкой (отсюда и -X, чтобы .psqlrc ничего не выполнил до этого). И выполнить его нужно в каждой базе, где установлено расширение, а не только в базе NetXMS.

Если ALTER EXTENSION всё же падает с той же ошибкой — поставить обратно пакет с 2.26.3, выполнить ALTER EXTENSION timescaledb UPDATE при живой старой библиотеке, затем снова обновить пакет до 2.27.2.

После этого повторить nxdbmgr upgrade. По состоянию базы: каждый шаг апгрейда выполняется в отдельной транзакции, DDL в PostgreSQL транзакционный, поэтому откат снял шаг 62.2 целиком — недоприменённых изменений не осталось, база консистентна и стоит на схеме 62.1. Повторный запуск безопасен, но dump перед ним сделать стоит.

Важное следствие: схема уже 62.1, а сервер требует точного совпадения версии схемы, поэтому сейчас не стартует ни 6.2.2 (ждёт 62.35), ни 6.1.2 (ждёт 61.36) — в логе будет "Your database has format version ...". Путь только вперёд, откат назад — это восстановление из бэкапа.

На то, что nxdbmgr показывает это состояние ошибкой, по которой причину не видно, завёл тикет: https://github.com/netxms/netxms/issues/3540. И отдельно на документацию, https://github.com/netxms/netxms-doc/issues/65 — в разделе про апгрейд про обновление расширения не сказано ничего.

И раз апгрейд всё равно не завершён: сегодня вышла 6.2.3, https://www.netxms.org/forum/announcements/netxms-6-2-patch-release-3/ — имеет смысл ставить сразу её. На эту ошибку она не влияет, шаг 62.1 → 62.2 в ней тот же самый, добавлены только шаги после него (схема 62.38 вместо 62.35).

Если extversion в базе окажется уже 2.27.2 — тогда картина другая, покажите вывод запроса и полный вывод nxdbmgr upgrade.