NetXMS Support Forum

But do you build agent with encryption enabled? I remember that on some stage of debugging you was rebuilding it without encryption.

Исправленный alarm viewer есть здесь: https://www.netxms.org/forum/general-support/alarm-browser-gt-netxms-console-fatal-error/msg7982/#msg7982. Alarm notifier посмотрю, там скорее всего таже самая проблема.

Can you show me screenshot of authentication properties in console for this node? nxget works fine with authentication, so server should also work.

Best regards,
Victor

Currently cluster objects works like a special kind of templates - DCIs defined on it applied to underlying nodes, exactly as from template. If cluster objects will also have active DCIs collected on it's own, it will somehow break current concept of node objects being only objects where data collection occurs. Also, there are cases when you don't have cluster object, but still need some common values - for example, total number of users connected to farm of terminal servers. Using one of the nodes is not very elegant and intuitive, as such values related to node group, not only one node. One possible solution would be to add data collection capabilities to container objects as well. Or, we can introduce some new object class for such DCIs. Another question is thresholds on such parameters - what object should be event source in case of threshold violation? I like to got to clear and elegant solution. Any thoughts?

Best regards,
Victor

Hi!

Just try to connect to agent via ssh port forwarding - it responds correctly. I see in your config that you turn on authentication on agent - but do you enter correct authentication parameters in node properties? Currently everything is correct in my test:


C:\Source\NetXMS\x64\debug>nxget -e 0 -p 4444 -a sha1 -s <secret> 127.0.0.1 Agent.Version
1.2.1


and on the agent:


[31-Jul-2012 19:16:26] Incoming connection from 127.0.0.1
[31-Jul-2012 19:16:26] Connection from 127.0.0.1 accepted
[31-Jul-2012 19:16:26] [session:0] Received control message CMD_GET_NXCP_CAPS
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_NXCP_CAPS (size 16)
[31-Jul-2012 19:16:26] [session:0] Received message CMD_AUTHENTICATE
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_REQUEST_COMPLETED (size 32)
[31-Jul-2012 19:16:26] [session:0] Received message CMD_KEEPALIVE
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_REQUEST_COMPLETED (size 32)
[31-Jul-2012 19:16:26] [session:0] Received message CMD_GET_PARAMETER
[31-Jul-2012 19:16:26] [session:0] Requesting parameter "Agent.Version"
[31-Jul-2012 19:16:26] [session:0] GetParameterValue(): result is 0 (SUCCESS)
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_REQUEST_COMPLETED (size 56)
[31-Jul-2012 19:16:26] [session:0] Session with 127.0.0.1 closed


Best regards,
Victor

Да, это поле node_flags. Флаг "disable configuration poll" имеет значение 0x20000000. Сам SQL запрос будет зависеть от базы, насколько я понимаю стандарта на битовые операции в SQL нет.

As all previously stored values displayed correctly now, that means a bug on client side - either in client library or in management console itself. Can you check any other string DCIs if you have any?

Best regards,
Victor

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