NetXMS Support Forum

Это новый management client, он пока что в процессе разработке, публикуется чтоб люди могли посмотреть куда идет развитие. В старом nxmc есть весь функционал.

Мы добавим в следующем релизе в логе более подробную информацию, что было причиной этого curl_easy_perform()

Yes, there is json support in nxsl, there is JsonParse() which would produce JsonObject or JsonArray. Support for jsons which have array at the root level (which is the case in your example) was added just recently, it will be available in next patch release. So after that release is out you could do something like this:

s = """[
   {
      "id": 178
   },
   {
      "id": 179
   },
   {
      "id": 181
   }
]""";
       
p = JsonParse(s);
println(classof(p));       
count = 0;
for (v: p->values) {
  println(classof(v));
  count = count + v->get("id");
}
println(count);


which would produce the following:
Result:

JsonArray
JsonObject
JsonObject
JsonObject
538


*** FINISHED ***

There are two options - to send value for a single DCI or for a number of DCIs (array is used in this case);

One value:
{
      nodeId : 10,
      dciId : 20,
      value : "Value"
}


Or, alternatively node name and DCI name (parameter name) can be used:
{
      nodeName : "Node name",
      dciName : "DCI name",
      value : "Value"
}


When sending multiple values:
data :
[
   {
      nodeId : 10,
      dciId : 20,
      value : "Value"
   },
   {
      nodeName : "Node name",
      dciName : "DCI name",
      value : "Value"
   }
]

I've created an issue for this feature, you can watch the issue to see when it's done (also there's no exact plan when this could happen).
https://track.radensolutions.com/issue/NX-2294

Yes, I did not mention this - config policies are not actually modifying the main agent config file. Each policy confiig is kept in a separate file in config_ap under agent's DataDirectory (by default C:\Windows\System32\ config\systemprofile\ AppData\Local\nxagentd on windows). When agent starts it reads these files. In recent agent versions it dumps actual configuration into it's log file, so your line should be visible there.

In properties of a DCI on Thresholds page there is "Instance name" field. Value from this field goes into the 6-th parameter of the event.

In event log viewer, if you double-click an event, you'll see event details with all parameters, e.g.:

   "id": 112780,
   "rootId": 0,
   "code": 17,
   "name": "SYS_THRESHOLD_REACHED",
   "timestamp": 1661420446,
   "originTimestamp": 1661420446,
   "origin": 0,
   "source": 5919,
   "zone": 0,
   "dci": 4512,
   "severity": 1,
   "message": " Threshold reached for data collection item \"Free space on file system /\" (Parameter: FileSystem.Free(/); Threshold value: 0; Actual value: 29226643456; instance THIS_IS_INSTANCE)",
   "lastAlarmKey": "DC_THRESHOLD_0x0000171F_0x000011A0",
   "lastAlarmMessage": " Threshold reached for data collection item \"Free space on file system /\" (Parameter: FileSystem.Free(/); Threshold value: 0; Actual value: 29226643456; instance THIS_IS_INSTANCE)",
   "tags": null,
   "parameters": [
      {
         "name": "dciName",
         "value": "FileSystem.Free(/)"
      },
      {
         "name": "dciDescription",
         "value": "Free space on file system /"
      },
      {
         "name": "thresholdValue",
         "value": "0"
      },
      {
         "name": "currentValue",
         "value": "29226643456"
      },
      {
         "name": "dciId",
         "value": "0x000011A0"
      },
      {
         "name": "instance",
         "value": "THIS_IS_INSTANCE"
      },
      {
         "name": "isRepeatedEvent",
         "value": "0"
      },
      {
         "name": "dciValue",
         "value": "29226643456"
      }
   ]


For many events parameters have names and you can also use macros with event names, e.g.  %<instance> instead of %6

Have a look at "Agent policies" in templates. One of the option is "Agent configuration" policy, where you can specify agent config lines. When template is added to a node, these config lines will be sent to agent and will start working after agent restart.

This is strange. What object it is - a node or something else? Which exactly version of nxmc and the server?

In action properties you need to specify hostname/ip address of the machine where your netxms agent is running. This is made so for greater flexibility, as event may be coming from one node, but you might need to execute the action on another system, for example.

You can use %a macro in "Remote host" field - in this case IP address of node where the event is coming from will be used.

Попробуйте в Tools ->Server console дать эти две команды
debug nc.* 7
debug ncd.* 7

это поднимет уровень отладки для сообщений относящихся к notification channel. Дальше нужно подождать пока такие события еще раз повторяться и посмотреть что в серверном логе.

By the way, what was exactly status of the node when IPv6 problem occurred? Was it unreachable? Currently on status poll, if node does not respond server should try to ping all IP addresses on all interfaces - this way server would know that the node is up, but there will be no communication to agent or SNMP.

Current approach, when hostname is resolved into single IP address and then communication is done to that address is quite deep in the architecture of NetXMS. In theory it could be possible to try other addresses on status poll, but this would be quite big programming effort and status poll would last for way longer when a node legitimately would go down.

What can be done however - we can add server setting to prefer IPv4 addresses when resolving node's hostname.

А можете собрать лог сервера на 6 уровне в момент подключения nxmc с другой машины? Для этого в nxmc Tools->Server console дать команду
debug 6
попробовать подключиться и потом дать команду
debug 0

лог будет в C:\netxms\log\netxmsd

и какая точно версия сервера и nxmc ?

Currently not really possible. I've just created an issue: https://track.radensolutions.com/issue/NX-2292
When this issue would be fixed, it would be possible to select some node connected to that specific interface of the core switch as seed node. Then in filter script you'd be able to filter out the core switch and it won't go pass the core switch when building the map.

You may also try adding
LocalHostName=localhost
into the configuration - some smtp servers may require this.

To troubleshoot - set debug level 6 for tags nc and ncd.smtp:
debug nc 6
debug ncd.smtp 6
in server console.
Then try to send a notification, server log should have some information.
Since smtp is not encrypted, you can also use tcpdump/wireshark to see communication with smtp server.