NetXMS Support Forum

Первый вопрос - на какой версии все это происходит, потому что print a; уже достаточно давно переделан в print(a);

t = AgentReadTable($node, "System.InstalledProducts");
for (row : t->rows)
{
  if (row->get(0) like "*Agent*")
  {
    s = "";
    for(cell : row->values)
    {
      s = s . cell . "-";
    }   
    println(s);
  }
}

This error was fixed, fix will be included in patch release that should be out this week.

In event processing policy you can use a filter script like this:
ifName = $dci->instance;
if (ifName == null or ifName == "") return false;

dciDescription = "Port Speed auf " . ifName;
portSpeed = GetDCIValueByDescription($node, dciDescription);

if (portSpeed->contains("HD")) return false;

return true;


$dci->instance will work if your DCIs are created by instance discovery, otherwise you might need to get the interface name by parsing description.

Alternative approach could be to use script threshold on your network error DCIs - that script could also get value of port speed DCI and generate threshold violation event only when both conditions are met. This way you would have less events (which also consume resources as they are stored in the DB).

Feel free to ask if you need more script examples.

Please add
DebugLevel = 6
to agent config file and share full agent log since it's start till sessions run out. You can share the log in private message if needed.

Make a script named getPackageVersion in script library:

packageName = $ARGS[1];
if (packageName == null) return "package name not provided to script";
for (s : $node->softwarePackages) {
  if (s->name == packageName) {
    return s->version;
  }
}
Then create a script DCI with metric e.g.:
getPackageVersion("curl")
The script is using information about packages collected during configuration poll, so it will provide a value even if the agent is not available at the moment.

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