You can configure Processing Policy like in attached image.
Note a difference between variables %i and %I. They are points to a same data - object ID but %i represent it in hex value and %I represent in decimal value. Used in script $node->id returns value in decimal, so the timer key must be generated with decimal value too.
"А ларчик просто открывался"... 
И.А. Крылов
Скрипт Instance Discovery:
transport = CreateSNMPTransport($node);
SensorType = SNMPGetValue(transport, ".1.3.6.1.4.1.9.9.91.1.1.1.1.1.".$1);
if (typeof(SensorType) == "null") {
return false;
}
switch (SensorType)
{
case "1":
MU = "other";
break;
case "2":
MU = "unknown";
break;
case "3":
MU = ", VAC";
break;
case "4":
MU = ", VDC";
break;
case "5":
MU = ", mA";
break;
case "6":
MU = ", W";
break;
case "7":
MU = ", Hz";
break;
case "8":
MU = ", ˚C";
break;
case "9":
MU = ", %RH";
break;
case "10":
MU = ", RPM";
break;
case "11":
MU = ", CMM";
break;
case "14":
MU = ", dBm";
break;
}
return %(true,$1,$2.MU);
Пропущены значения 12 (truthvalue) и 13 (specialEnum), чего с ними делать пока не решил 
Картинка с результатом прилагается.
Понадобилось иметь информацию об оптических модулях установленных в коммутатор. В процессе разбирательств образовался алгоритм позволяющий собирать все данные со всех сенсоров устройства, что в последствии оказалось весьма удобным. Возможно кому-то будет интересно...
Попутный вопрос: Подскажите, как менять имя инстанции в процессе работы фильтра Instance Discovery. [SOLVED]
Понадобятся данные из 4-х SNMP OID-ов:
.1.3.6.1.4.1.9.9.91.1.1.1.1.4 - значение сенсоров
.1.3.6.1.2.1.47.1.1.1.1.7 - имена физических устройств.
.1.3.6.1.4.1.9.9.91.1.1.1.1.1 - тип физического устройства, если у OID-а есть значение, то это сенсор. По цифре значения определяется единица измерения (Volts,Ampers,Watts...)
.1.3.6.1.4.1.9.9.91.1.1.1.1.3 - точность сенсоров (количество знаков после запятой)
Создаем Template, в нем DCI со следующими параметрами:
Description = {instance-name}
Paramater = .1.3.6.1.4.1.9.9.91.1.1.1.1.4.{instance}
Origin = SNMP, Data type = Floating Point Number
В Instance Discovery определяем инстанции:
Instance discovery method = SNMP Walk - OIDs
Base SNMP OID = 1.3.6.1.2.1.47.1.1.1.1.7
Нужно разрешать только сенсоры имеющие единицы измерений, поэтому на Instance Discovery ставится фильтр:
transport = CreateSNMPTransport($node);
SensorType = SNMPGetValue(transport, ".1.3.6.1.4.1.9.9.91.1.1.1.1.1.".$1);
if (typeof(SensorType) == "null") {
return false;
}
return true;
Для правильного вывода данных нужно установить "запятую" на место:
sub_oid = right($dci->name,4);
transport = CreateSNMPTransport($node);
prec = SNMPGetValue(transport, ".1.3.6.1.4.1.9.9.91.1.1.1.1.3.".sub_oid);
if (prec == 1) {
return $1/10;
}
if (prec == 2) {
return $1/100;
}
if (prec == 3) {
return $1/1000;
}
return $1;
Темплейт можно автоматом привязывать к узлу. Automatic Apply Rules = return $node->sysDescription like "Cisco *";
Для полного счастья не мешало бы добавлять в имя инстанции единицы измерения, из .1.3.6.1.4.1.9.9.91.1.1.1.1.1 Но сделать это у меня не получается, видимо чего-то недопонимаю... Решение в посте ниже.
Виновником такого поведения оказался Out Of Memory Killer. Статья с сайта Oracle: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html
После установки 'kernel.shmmax', процесс netxmsd OOM Killer вроде бы перестал трогать, а стал убивать процесс tomcat-а.
Дальнейшее копание привело к этой статье https://plumbr.io/blog/memory-leaks/out-of-memory-kill-process-or-sacrifice-child, а в частности к комментарию в конце, и к 'kernel.shmmax' было так же добавлено 'vm.swappiness = 5'.
С такими настройками сервер благополучно пережил длинную праздничную ночь с пятницы на вторник. Тенденция роста занимаемой процессом netxmsd памяти, однако сохраняется.
~$ cat /etc/sysctl.conf
kernel.shmmax = 2000000000
vm.swappiness = 5
Возможно поможет изменение 'shmmax'. Взято отсюда: https://www.netxms.org/forum/installation/1-2-16-database-migration-out-of-memory-(solved)/
kernel.shmmax = 2000000000
Добавлено с sysctl.conf
$ sysctl -a | grep shmmax
kernel.shmmax = 2000000000
Буду наблюдать...
Добрый день.
После обновления с версии 2.0.8 на 2.1.2 обнаружилось крайне неприятное поведение. Процесс netxmsd стал неожиданно завершать работу. В логах ядра обнаружилось вот такое сообщение:
Nov 2 21:50:14 hostname kernel: [14817161.433447] Out of memory: Kill process 21117 (netxmsd) score 27 or sacrifice child
Nov 2 21:50:14 hostname kernel: [14817161.433805] Killed process 21117 (netxmsd) total-vm:2699144kB, anon-rss:226604kB, file-rss:9100kB
Программа установлена на сервере Ubuntu Linux и репозитория.
$ uname -a
Linux hostname 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ apt list --installed | grep netxms
netxms-agent/xenial,now 2.1.2-1 amd64 [installed]
netxms-base/xenial,now 2.1.2-1 amd64 [installed,automatic]
netxms-dbdrv-pgsql/xenial,now 2.1.2-1 amd64 [installed]
netxms-dbdrv-sqlite3/xenial,now 2.1.2-1 amd64 [installed,automatic]
netxms-release/now 1.1 all [installed,local]
netxms-server/xenial,now 2.1.2-1 amd64 [installed]
Как это лечить?