NetXMS Support Forum

range 192.168.139.1 - 192.168.135.254  - this was incorrect debug message, was just fixed will be in next patch release.

What exactly version you currently use?

But how it goes currently, it gets detected with CISCO-GENERIC driver?

You can actually force CISCO-SB by setting custom attribute snmp.driver to CISCO-SB. If so, would all information get collected correctly or would there be any issues?

It uses 16 out of max 16 threads which means that at some point they were needed and were populated. And avg wait time of about 0.5 second tells that there are moments when it's doing something.
Graph of current load for 24 hours could tell more, but looks like it's not too busy. It definitely had been busy when discovering this network for the first time, but now addresses for which nodes are already created are not polled in this thread pool any more.

You can add another active discovery range that would include just on of these switches that are not getting added, turn on 6 debug level for poll.discovery and do a scan manually only for this specific range. This way log would have just the information we need.

Actually this is a bug - in last values it should be displayed the same way as in history. This will be fixed.

In the future custom formatting will be implemented - you can follow this issue: https://track.radensolutions.com/issue/NX-2265

Is there any chance that you could provide remote access to such a device to our developers? That would be the easiest way to develop the driver.

/16 might not be too bad idea. Initial pinging is real fast - it goes in blocks of 1000 addresses and takes a few seconds.
Then there is second stage of discovery - when server tries to connect to nodes to get some information. This and subsequent configuration poll for newly-added nodes occurs in DISCOVERY thread pool.

In Tools -> Server Console you can do
show queues
"Node discovery poller" should show the number of addresses waiting.
show discovery queue
should give a list of addresses.

show threads
DISCOVERY part should tell how busy this pool is, may be it should be increased in size.

On your server node there is a number of internal DCIs that keep historical stats for the above.
Server.QueueSize.Current(NodeDiscoveryPoller) is the actual queue size. Is should get to 0 during these 900 seconds. Would be interesting to see it's graph.

Server.ThreadPool.Load(DISCOVERY) and a few other for thread pools should tell how busy discovery thread pool is and if you need to make it bigger.


And if you want to dig deeper, you can turn on say 6 level of debug for tag poll.discovery. This should produce a lot of information in the server log.

That would be in "Data collection configuration" of a node where this data is collected from.
In properties of data collection item select Transformation tab and choose Average delta per minute.

Please enable system user and login under it. Then try searching in object tree, may be there are nodes with these IP addresses that are, however, not visible to your regular admin account.

You can use delta in the settings of the DCIs - in this case you will have number of events par minute for example.

This depends on whether your DCI is string or float. Looks like it's float - in this case displaying works with 6 digits after comma. If you select string it will probably show as you like.

Business services were totally reworked in 4.0 with a lot of new options - it's now possible to automatically populate them and add checks, etc.
Looks like dashboard element was totally forgotten during the rework.
I will check with developers about this and availability percentages.

return format($1/100000, 1, 5);

should do the job. https://www.netxms.org/documentation/nxsl-latest/#func-format

Discovery settings in gui just reflect a number of Server Configuration Variables. So you can do script DCI (or Dummy internal DCI with transformation script) and have this:

return GetConfigurationVariable("NetworkDiscovery.Type");

Очередь формируется автоматически, когда приходит время делать какой-нибудь из поллов. Настроить можно только интервал поллов или количество тредов, занимающихся поллингом.

В Tools->Server console можно сделать
show queue
там будет число для Pollers.

По тредам там же
show threads

Если вы вручную запускаете полл сразу после создания ноды, то Poll request accepted, waiting for outstanding polling requests to complete - это нормальная ситуация, т.к. configuration и status поллы сразу запускаются автоматически.

Вот пример скрипта. Он берет значения из левой колонки (0 в get(r, 0), следующая колонка будет 1 и т.д.).

for(r = 0; r < $1->rowCount; r++)
{
   v = $1->get(r, 0);
   if (v->startsWith("GigabitEthernet"))
   {
      $1->deleteRow(r);
      r--;
   }
}