NetXMS Support Forum

Quote from: SKYnv on July 31, 2012, 01:58:15 PM
А не опишите что конкретно для работы необходимо? я попинаю разработчика, у меня есть выходы на него.

В идеале - поддержка interface и IP MIB - ветки .1.3.6.1.2.1.2 и .1.3.6.1.2.1.4.20, хотя-бы только статическая информация - индекс интерфейса, MAC адрес, IP адрес. Как вариант - добавить два параметра в ветке .1.3.6.1.3.120.4 - MAC адрес и маска для IP адреса. Тогда я сделаю простой драйвер, который будет из этого MIB-а брать информацию.

Quote from: SKYnv on July 31, 2012, 01:58:15 PM

QuoteПри этом как значение sysObjectID возвращается .0.1.

то есть это неверно?

Да, должно быть что-то из .1.3.6.1.4.1, ну или если еще не выделен свой enterprise id, то наверное из experimental, где сейчас находится MIB для устройства (.1.3.6.1.3.120).

Quote from: SKYnv on July 31, 2012, 01:58:15 PM
А если просто опрос по ip и нужным oid'ам? устройство то простецкое. Сбор температуры.

Так это ведь вроде как работает? У меня устройство определилось как SNMP устройство, и получать значения по SNMP с него можно было - единственная проблема вообсчем-то, что нет информации об интерфейсах, роутинге, и т.д.

Hi!

It looks like problem on server or in management console, because history is corrupted. Last value always good, which means that agent reports correct value. Can you try to change data type of this DCI to integer? Also, is there any other DCIs which experience same problem?

Best regards,
Victor

Посмотрел. SNMP агент на этом устройстве фантастически убогий - он не возврасчает практически ничего из стандартных MIB-ов - только sysName, sysDescr, и sysObjectID. При этом как значение sysObjectID возвращается .0.1. MAC адрес с него получить в принципе невозможно. Так что особо тут ничего не сделаешь. Вот полный SNMP WALK для устройства:


C:\Source\NetXMS\x64\debug>nxsnmpwalk -v 1 -c public -p1616 178.216.65.102 .1
.1.3.6.1.2.1.1.2.0 [OBJECT IDENTIFIER]: .0.1
.1.3.6.1.2.1.1.1.0 [Hex-STRING]: 0A 20 74 20 33 31 20 27 43 0A 20 44 6F 6F 72 20 69 73 20 4F 46 46 20 20 0A 20 56 6F 6C 74 61 67 65
20 69 73 20 4F 46 46 0A 20 31 73 74 20 73 65 6E 73 20 69 73 20 4F 46 46
.1.3.6.1.2.1.1.5.0 [STRING]: ERD-3.0_1:015:180
.1.3.6.1.3.120.4.1.0 [IP ADDRESS]: 10.255.141.201
.1.3.6.1.3.120.4.2.0 [IP ADDRESS]: 10.255.141.1
.1.3.6.1.3.120.4.3.0 [IP ADDRESS]: 0.0.0.0
.1.3.6.1.3.120.4.4.0 [IP ADDRESS]: 192.168.1.170
.1.3.6.1.3.120.5.1.0 [INTEGER]: 0
.1.3.6.1.3.120.5.2.0 [INTEGER]: 0
.1.3.6.1.3.120.5.2.1.0 [INTEGER]: 0
.1.3.6.1.3.120.5.3.0 [INTEGER]: 0
.1.3.6.1.3.120.5.3.1.0 [INTEGER]: 0
.1.3.6.1.3.120.5.4.0 [INTEGER]: 0
.1.3.6.1.3.120.5.4.1.0 [INTEGER]: 0
.1.3.6.1.3.120.5.4.2.0 [INTEGER]: 0
.1.3.6.1.3.120.5.5.0 [INTEGER]: 31
.1.3.6.1.3.120.5.5.1.0 [INTEGER]: 28
.1.3.6.1.3.120.5.5.2.0 [INTEGER]: 0
.1.3.6.1.3.120.5.5.4.0 [INTEGER]: 0
.1.3.6.1.3.120.5.6.0 [INTEGER]: 1
.1.3.6.1.3.120.5.2.2.0 [INTEGER]: 10
.1.3.6.1.3.120.5.1.1.0 [INTEGER]: 0
.1.3.6.1.3.120.5.5.3.0 [INTEGER]: 0
.1.3.6.1.3.120.5.5.5.0 [INTEGER]: 0
.1.3.6.1.3.120.6.2.3.0 [STRING]: 1st sensor
.1.3.6.1.3.120.6.2.4.0 [STRING]: 2nd sensor
.1.3.6.1.3.120.6.2.5.0 [STRING]: 3rd sensor
.1.3.6.1.3.120.6.2.1.0 [STRING]: ALARM
.1.3.6.1.3.120.6.2.2.0 [STRING]: ALARM2
.1.3.6.1.3.120.6.3.0 [INTEGER]: 0
.1.3.6.1.3.120.6.1.0 [STRING]: public

C:\Source\NetXMS\x64\debug>


You need only one such DCI, not on each node. As it's source is "Internal", it will be collected even if node is down, because it does not involve any communication with the node - everything is inside server process. You can put this DCI on your dashboard. In more details, you should have configuration similar to this:

Cluster node A:
   "agent" DCI for running VMs
   "agent" DCI for stopped VMs
   "agent" DCI for saved VMs

Cluster node B:
   "agent" DCI for running VMs
   "agent" DCI for stopped VMs
   "agent" DCI for saved VMs

Cluster node C:
   "agent" DCI for running VMs
   "agent" DCI for stopped VMs
   "agent" DCI for saved VMs

Any node (could be any cluster node, or management server itself, or any other):
  "internal" DCI, parameter name "Dummy", for total running VMs
  "internal" DCI, parameter name "Dummy", for total stopped VMs
  "internal" DCI, parameter name "Dummy", for total saved VMs

  each of these DCIs should have transformation script similar to this:

return GetDCIValueByName(FindNodeObject($node, "node-a"), "running_vms_parameter") +
   GetDCIValueByName(FindNodeObject($node, "node-b"), "running_vms_parameter") +
   GetDCIValueByName(FindNodeObject($node, "node-c"), "running_vms_parameter");


The only problem remains is if when cluster node down and value of appropriate parameters is not 0 - then you will get incorrect totals. You can add additional checks in the script, like this:


sub getValue(nodeName, paramName)
{
   node = FindNodeObject($node, nodeName);
   if (node == null)
      return 0;

   dci = GetDCIObject(node, paramName);
   if ((dci->status != 0) || (dci->errorCount > 0))
      return 0;

   return GetDCIValue(node, dci->id);
}

return getValue("node-a", "running_vms_parameter") +
   getValue("node-b", "running_vms_parameter") +
   getValue("node-c", "running_vms_parameter");


Best regards,
Victor

64-bit version of libnxsrv.dll.

Hi!

I'm already back from vacation I don't know exact release date for 1.2.3 yet. Most likely it will be somewhere in the end of August.

Best regards,
Victor

Hi!

It should be the problem. Attached is recompiled libnxsrv.dll for 32 bit Windows.

Best regards,
Victor

Hi!

You have to create additional DCI on any node, which will accumulate values from all cluster nodes. You can create DCI with internal source and parameter "Dummy", and use NXSL functions GetDCIValueByName or GetDCIValueByDescription in transformation script for getting values from individual cluster nodes. Don't forget to turn off trusted node check or add target node to trusted nodes list on all cluster nodes (see also this page: http://wiki.netxms.org/wiki/SG:Security_Issues).

Best regards,
Victor

I have fixed this error. Agent compiles both with and without all-static flag. I'm not sure if it will work correctly with ODBC and all-static, because ODBC uses dynamic linking internally to load drivers, but you can check. Agent compiled without all-static should work without problem, but it will depend on system shared libraries - only NetXMS libraries and subagents will be included into nxagentd binary. Updated source package can be downloaded from here: https://netxms.org/download/patches/014/netxms-1.2.2.tar.gz.

Best regards,
Victor

Yes, it should, but due to a bug existed before 1.2.2, some interfaces have stalled peer information. It should be cleared when you connect new devices to ports with wrong information, or when device incorrectly pointed as peer will be moved to yet another port. I'll also consider possibility to add background peer validation in 1.2.3 to clear incorrect peer information.

Best regards,
Victor

Quote from: SKYnv on July 30, 2012, 10:37:07 AM
и еще
4) Netxms добавляет vlan'ы в дерево портов устройства чем неимоверно захламляет его

NetXMS добавляет все интерфейсы, о которых сообщает устройство. Сделать какой-то стандартный алгоритм отсечения "ненужных" интерфейсов не думаю что возможно, к тому-же это сильно зависит от конкретной инсталляции - где-то такие интерфейсы нужны, где-то нет. Можно подумать над добавлением неких фильтров, которые можно будет делать самому, для исключения из базы интерфейсов, которые не нужны. Еще один нюанс, о котором надо помнить - интерфейсы, на которых определены IP адреса, должны быть -иначе нарушится IP топология.

You can try to rebuild agent with --disable-iconv option. If this will not help, can you consider giving me shell access to it so I can debug the issue?

Best regards,
Victor

Hi!

"Interfaces" tab is a new feature in 1.2.2, but interface peer tracking is there since some version in 1.1.x branch. This information was shown previously in object overview tab for interface objects. You can clear that by deleting interface object with wrong peer information and running configuration poll - server will rediscover interface and create new interface object without peer information.

Best regards,
Victor

Hi!

Switch reports interface operational status as 2 (down) for 2 of them and 6 (notPresent) for other two on each unit. NetXMS server translates "notPresent" state into UNKNOWN status, this is why you see some of 10G interfaces as unknown. It's a question if this is a correct interpretation of interface state, or it should be translated into CRITICAL status, as for DOWN state.

Best regards,
Victor

Не смог подключится по SNMP, только на web интерфейс. Было бы очень полезно SNMP доступ получить тоже. По wireless bridge - а как у них выглядят интерфейсы?