NetXMS Support Forum

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.

Here's an example of map filter script to start with.
if ($node->name == "sw-shelf") return true;

for (i:$node->interfaces) {
  p = i->peerInterface;
  n = i->peerNode;
  if (n != null and p != null and n->name == "sw-shelf" and p->name->contains("gi1/0")) return true;
}
return false;
It shows sw-shelf node and nodes connected to ports of the switch that have names beginning with "gi1/0".

But this script only shows directly connected devices. Do I understand correctly, that you actually want all the hierarchy that is connected to a specific port of your core switch?

There is Object Filter in map properties. That's script that is executed for each node to decide if it should be added to the map.
So in that script you can loop through interfaces of the node, interfaces have peerInterface attribute. This attribute, if not null, will have interface object of the switch.

Pls send a note if you need an example of the script.

It looks that there's a space in nodetimer_ %i after _ sign when setting the timer.

In overall - do I understand correctly, that you want do delay node down notification and send node up notification only if node down notification was sent? If so, currently this can be achieved without scripting, by filling in "Snooze/Blocking timer key" field in recovery notification properties.

Yes, if interface is down, it goes to critical (and there's currently no way to configure that severity). But we can affect the way how this status goes up to parent object (switch).

In properties of the switch node you can select Multiple thresholds status calculation. Put 100% to critical and 0 to Warning, Minor, Major. This means that only if 100% of child objects will go to critical, the node will become critical. So it should do the job.

You can also use smaller number there, e.g. if 50% of interfaces...

At some point external parameters started to capture STDERR in addition to STDOUT. Most probably your script produces some sort of textual error that is being captured. Then NetXMS tries to interpret it as integer and this way it becomes 0.

You can check with nxget
nxget IP_ADDRESS_OF_AGENT name_of_the_parameter