NetXMS Support Forum

Hi,

We had a discussion with developers and formulated how this could be implemented somewhere in the future: https://track.radensolutions.com/issue/NX-2466

For the time being, you can create dummy nodes (specifying ip address 0.0.0.0), create one script DCI on each of these nodes with "Use this DCI for node status calculation" and use script to determine status (script should be returning 0...4 for Normal...Critical)

Please try this way:

systemctl stop netxmsd
netxmsd -D 6

NetXMS server will start in foreyground mode and will put log messages onto the screen. Then try to log in from the client and observer what's happening in the terminal - will server continue to run or will it fail.

QuoteI have problem too. My enveropment:
Docker, Ubuntu 18.04, PG 12.5, NetXMS 4.4.2

Do you have netxms-server-dbg package installed on your system? If not, please install it and make the backtrace again.

Please check server log - one possible issue is that server is crashing on client connection. Please check server log.

If this is the case, try stopping server via systemd:
systemctl stop netxmsd

and running it in foreground:
netxmsd -D 6

in this mode server will be running on debug level 6 and will output it's log to the terminal. Please share last log lines prior to the crash and repeat this 2 times.

Я попробовал сделать скрипт, который автоматом берет скорость интерфейса и считает лимит отсечки в 120% от скорости. Строчки trace(0, ...  пишут отладочные сообщения в лог сервера, для нормальной работы их нужно убрать.

Скрипт годится только для тех DCI, которые создавались механизмом instance discovery - у них тогда заполнен атрибут instance. Скрипт ищет интерфейс под нодой, имя которого совпадает с instance, это будет работать для агентских метрик, для snmp instance будет индексом интерфейса и в 6-й строчке вместо i->name нужно использовать i->ifIndex

В целом получилось сложно, лучше наверное дождаться когда разработчики добавят эту обработку в код.

trace(0, $dci->name . ", $1: " . $1);
lastValue = GetDCIValue($node, $dci->id);
trace(0, "lastValue: " . lastValue);
speed = 0;
for (i: $node->interfaces) {
  if (i->name == $dci->instance) speed = i->speed;
}
trace(0, "speed: " . speed);
if (lastValue == null or speed == 0) return $1 * 8; // could not do much
upperLimit = int64(speed / 8L * 1.2); // in bytes
trace(0, "upperLimit: " . upperLimit);
if ($1 > upperLimit) return lastValue;
trace(0, "returning $1*8: " . $1 * 8);
return $1 * 8;
Если интерфейс продолжает существовать и счетчики трафика на нем не меняются, то скрипт должен корректно отдавать значение 0.

Если это старая консоль, то там в десктопной версии был баг, после смены языка ее нужно полность закрыть и открыть снова. Возможно даже дважды.

В новой консоли локализация пока не сделана, так что она только английская

Map improvements are currently in development, expected to be included to 5.0 in a few months.

Проблема такого скрипта - не получится пропустить сбор значения - теоретически это можно сделать командой abort, но при этом не сохранится raw значение и вычисление дельты пойдет от последнего собранного raw значения.
Так что лучшее, что сейчас может делать такой скрипт - возвращать еще раз последнее собранное значение - если нужно, сделаю пример.

Отображение с Mbps работает в last values. В history его не сделали еще, в 5.0 наверное будет.

Уточнил у разработчиков - да, это сейчас оно действительно так работает. Дело в том, что переполнение счетчика может означать две вещи:
а) действительно на интерфейсе прошло столько байт, что считчик дошел до максимума и перешел через 0
б) счетчики на устройстве сбросились на 0 (рестарт устройства и т.д.)

В более старых версиях обработка шла исходя из первого случая - всегда выполнялось вычисление с unsigned числами. Проблема в том, что для ситуаций б) это давало высокий пик на графике, т.к. получалось очень большое число. Поэтому алгоритм поменяли, что если собираемое число уменьшилось, то преобразованное значение становится 0.

Это переделаем, вот тикет https://track.radensolutions.com/issue/NX-2461

На сейчас можно вместо counter32 выбрать unsigned integer, но тогда нужно скриптом защищаться от ситуации б) - проверять что значение не слишком большое.

Yes, currently this is as you described. I've created an issue in our bug tracker, you can follow it to see when it will be fixed:
https://track.radensolutions.com/issue/NX-2460

Yes, currently error is treated as true, which is not good. Will be changed to false in next release.

Yes, that's exactly how it works. If at some point server would be able to get info about interfaces from agent, this interface will be recreated with proper name.

Data type "Counter 32-bit" должен обрабатывать переход на 0 автоматически. Можно посмотреть в history по этому DCI - там будет колонка raw value. Покажите скриншот history в месте где raw value проходит через 0.

Возможно проблема в трансформационном скрипте - возможно за минуту набегает столько, что при умножении на 8 получается число большее, чем 32-битный integer. Для проверки можно сделать такой трансформационный скрипт (8L заставит выполнять 64-битную арифметику):

return (($1 *  8UL ) / 1024) / 1024;"

Но вообще вручную делить для получения мегабит уже не нужно - можно в свойствах DCI поставить Units "b/s" и Use multipliers "Default" или "Yes". Значение будет хранится в битах в сек и переводится при отображении. Если нужно чтоб всегда отображалось в Mbps, на закладке other options поставить Multiplier degree "Fixed to M".

Can you show a screenshot how these "unknown" name and description look like?
Is it so for all interfaces that are being created or for some (agent, snmp, with specific name?)
What if you try a simpler regex, without alternatives, would it change anything?

How much time does it take since agent restart to consume all the sessions?

In out-of-the-box template for the agent there are metrics
Agent.ActiveConnections
Agent.AcceptedConnections

please show graphs for these for the time since agent start till the sessions run out