NetXMS Support Forum

Ок, присылайте лог сервера. Можно в форумную личку.

NXSL tried to interpret the HEX as string and taked first 00 as end of string. Try this way:

transport = $node->createSNMPTransport();
if (transport != null)
{
  println transport->get(".1.3.6.1.4.1.4196.1.1.5.2.100.2.1.4.0")->printableValue;
}

Reporting perspective is showing reports that are installed in C:\NetXMS\var\nxreportd\definitions

Here's a forum post that has an example of report:
https://www.netxms.org/forum/general-support/reporting-server-4315/msg20117/#msg20117

You can use instance discovery mechanism - in this case DCI are created and their names can be used in graphs on Performance tab.

- Create a script in script library, e.g.:
instances = %{ }; // Create empty hash map

instances[".1.1.1"] = "name_one";
instances[".1.1.2"] = "name_two";

return instances;

- Create a DCI. In "General" tab in DCI properties there are two macros - {instance} and {instance-name}. E.g. ".1.1.1" from the script will go into {instance}, "name_one" into {instance-name}.

- In "Performance" tab in DCI properties the situation is opposite - {instance} will be filled with "name_one" (this is so for some historical reasons, should be changed in some future releases).

Now, when you do Poll->Instance discovery on a node (or wait when it would happen automatically), the script will be executed, values returned by this script will be used to create/update DCIs.


The script in the above example returns hash map. It could also return an array, in that case {instance} would be taken from that array. In instance discovery filter script it's possible to modify or add {instance} and {instance-name}.
return Instance(displayName: "name_one", name: ".1.2.3");

Now wee need to get the legend name. This could be done either from that script in script library or from instance discovery filter script:

transport = $node->createSNMPTransport();
if (transport != null) {
  legend_name = SNMPGetValue(transport, ".1.2.3.4.1");
}

There are some examples in NXSL docs: https://www.netxms.org/documentation/nxsl-latest/

Попробуйте на момент опроса узла поставить 6 уровень отладки на сервере (Tools -> Server console, там "debug 6", по окончании "debug 0"). Создайте интерфейс внучную, сделайте опрос и покажите лог сервера.

На закладке Object Details - Overview что записано в поле "Driver"?

Pls show the contents of C:\NetXMS\log\commons-daemon.xxxx-xx-xx.log

There are several approaches here
- you can create two DCIs - one for pinging with short packets, another for big packets. In a third, script, DCI you can read last collected values of these pinging DCIs
GetDCIValue($node, FindDCIByName($node, "DCI_NAME"))
and make decision. This script DCI can return e.g. 1 or 0 and have a trigger that creates event.

- You can have a script DCI that poll several agent parameters at once.
$node->readAgentParameter("Icmp.Ping(8.8.8.8, 1000, 1500)")
It's not recommended for such script DCI to run for very long (longer then 3-5 seconds) as having many such script DCIs may occupy data collection pollers for too long and cause problems with data collection.

For timeout Icmp.Ping returns value of 10000.

As answered in Telegram support channel:

Increase memory limit in nxmc.ini
(-XmxNNN, where NNN is the limit)

One way is to create a DCI on that node with Icmp.Ping(target, timeout, psize) metric. "psize" parameter defines packet size.
In "Source node" in DCI's properties you can select a node from which the ping will be actually sent.

Second way - you can manually add an interface with the external IP and then use ICMP statistic collection on that interface. But in this case it's not possible to set packet size.
https://www.netxms.org/documentation/adminguide/icmp-ping.html#

DRBD collector is for https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device , this may not be present on a system. So this is not an error that would be preventing server connecting to agent.

check output of
netstat -lptn
on agent's system. It should show something like
tcp        0      0 0.0.0.0:4700            0.0.0.0:*               LISTEN      6347/nxagentd       
that would mean that NetXMS agent is listening on port 4700.

From another machine you can try
telnet agent_machine_ip 4700
to see if it's possible to establisth network connection to agent.

In netxms console try right-clicking the node and performing Configuration Poll (full).

Where exactly does this show up? Does it happen on nxmc startup or something should be done? If something, what exactly, what tab should be opened?

chances are that adding
else
{
  return false;
}
will fix the issue.


In overall you can use
trace(0, "your debug");
PollerTrace("your debug");
to debug what's happeing. First one adds to server log, the latter - to the output of poll messages when you do e.g. Configuration poll from node's context menu.

In NetXMS every agent can operate as a proxy, collecting data from other agents, via SNMP, etc... If your locations have overlapping IP addresses, then you need to use zones. Event if addresses are not overlapping, it's convenient to use zones, as you can set proxies in zone properties and nodes added to this zone will be monitored via there proxies.

Proxies accumulate collected data if there's no connection to central server. Proxies have high availability mechanism - if more then one proxy is configured on a zone, proxies will extablish p2p communication between them to decide which proxy is collecting data.

There's a lot in admin documentation https://netxms.org/documentation/netxms-admin.pdf , but some things may be not yet covered, so feel free to ask questions.

This is actually already fixed, will be included in patch release that is coming soon.

And which database are you using?