NetXMS Support Forum

Yes, it is there for some time already: https://track.radensolutions.com/issue/NX-593.

Best regards,
Victor

Hi,

flag names didn't change since 2.2, just moved to separate "state" attribute. Runtime flag names from 2.2:

#define NDF_QUEUED_FOR_STATUS_POLL     0x000001
#define NDF_QUEUED_FOR_CONFIG_POLL     0x000002
#define NDF_UNREACHABLE                0x000004
#define NDF_AGENT_UNREACHABLE          0x000008
#define NDF_SNMP_UNREACHABLE           0x000010
#define NDF_QUEUED_FOR_DISCOVERY_POLL  0x000020
#define NDF_FORCE_STATUS_POLL          0x000040
#define NDF_FORCE_CONFIGURATION_POLL   0x000080
#define NDF_QUEUED_FOR_ROUTE_POLL      0x000100
#define NDF_CPSNMP_UNREACHABLE         0x000200
#define NDF_RECHECK_CAPABILITIES       0x000400
#define NDF_POLLING_DISABLED           0x000800
#define NDF_CONFIGURATION_POLL_PASSED  0x001000
#define NDF_QUEUED_FOR_TOPOLOGY_POLL   0x002000
#define NDF_DELETE_IN_PROGRESS         0x004000
#define NDF_NETWORK_PATH_PROBLEM       0x008000
#define NDF_QUEUED_FOR_INSTANCE_POLL   0x010000
#define NDF_CACHE_MODE_NOT_SUPPORTED   0x020000
#define NDF_NEW_TUNNEL_BIND            0x040000

In both 2.2 and 3.0 "unreachable" means that NetXMS server cannot reach the node for any reason. NETWORK_PATH_PROBLEM is an additional indicator to show that most likely node cannot be reached because of network problem on the path between NetXMS server and node (router down. etc.). Server reads routing tables from intermediate routers and builds path between itself and each node, so there is only one such path, and it either has problem or not. If there is redundant link routing eventually changes and node became reachable again, so both "unreachable" and "network path problem" flags will be cleared. NETWORK_PATH_PROBLEM flag determines what event will be generated - SYS_NODE_DOWN (if not set) or SYS_NODE_UNREACHABLE (if set).
To detect problems with non-working links you have interface objects and corresponding events.

Best regards,
Victor

Hi,

you should go to data collection configuration on the node, then edit DCI object - then you will see "Thresholds" page. You can also post some screenshots.

Best regards,
Victor

Похоже на 2019 проблема с доступом к PDH, System.Uptime берется оттуда-же.

System.IO.Devices - это список, его не будет в списке параметров. Если сделать

nxget -l ip_address System.IO.Devices

с Server 2019, что он выдаст?

It is now available in "state" attribute (not yet added to documentation). Possible flag values are:

UNREACHABLE = 0x00000001
NETWORK_PATH_PROBLEM = 0x00000002
AGENT_UNREACHABLE  = 0x00010000
SNMP_UNREACHABLE  = 0x00020000
CACHE_MODE_NOT_SUPPORTED  = 0x00080000

Best regards,
Victor

Сделал I/O параметры в субагенте WinNT (WinPerf теперь не нужен для этого). Поддерживаемые параметры:

System.IO.ReadRate
System.IO.ReadRate(*)
System.IO.WriteRate
System.IO.WriteRate(*)
System.IO.BytesReadRate
System.IO.BytesReadRate(*)
System.IO.BytesWriteRate
System.IO.BytesWriteRate(*)
System.IO.DiskQueue
System.IO.DiskQueue(*)
System.IO.DiskReadTime
System.IO.DiskReadTime(*)
System.IO.DiskTime
System.IO.DiskTime(*)
System.IO.DiskWriteTime
System.IO.DiskWriteTime(*)

В качестве инстанса передается номер диска. Список доступных дисков возвращает список System.IO.Devices.

Агент для тестов: https://cloud.netxms.org/index.php/s/sHxi8pcjhVWY0JU

I recommend using runtimeFlags field to determine that node is completely unreachable, like this:


if (($node->icmpresponse & 4) != 0)
   // state is "down"


Also few comments on script itself - purely style/clarity, not functionality:

1. You may use direct comparison instead of regexp match if you are loking for exact match, i.e.

(newstate == "Down")

instead of

(newstate imatch "Down")

2. No need for checking status twice, just can just use else:

if ($node->icmpresponse == "no") {
}
else {
}


Best regards,
Victor

Quote from: paul on July 19, 2019, 07:24:18 AM
Now, a container for those nodes that communication is down - which is not one of the available status codes - that is going to be tricky.

You can use runtimeFlags field of Node object - if it has bit 2 set then node in unreachable. Script to match can looks like this:

return ($node->runtimeFlags & 4) != 0;

Please note thoug that meaning of this field is changed in version 3.0.

Alternative approach is to catch SYS_NODE_DOWN event and in action script call BindObject to put node into container, and catch SYS_NODE_UP and use UnbindObject to remove node from container.

Best regards,
Victor

So server process is crashing. Please enable core dumps and either send coredump to us or get stack trace from it with gdb. You can also run netxmsd under debugger and get stack trace directly from there. Here is short instruction: https://wiki.netxms.org/wiki/Running_NetXMS_under_debugger

Best regards,
Victor

Hi,

you can use NXSL function GetInterfaceObject to get access to interface object and then RenameObject to rename it.

Best regards,
Victor

Hi,

one possible workaround is to use hook script on topology poll to collect information about devices connected to the switch and update custom attribute or comment on those devices. We also have request for adding "connection history" functionality to NetXMS so probably after some time system will keep track of ports used for device connection automatically.

Best regards,
Victor

Hi,

1) could it be that you did not restart agent after adding EnableSNMPProxy parameter to configuration?

2) Looks like a bug. What version you are using?

Best regards,
Victor

I suggest checking data collection templates (https://www.netxms.org/documentation/adminguide/data-collection.html#templates). Using templates with auto apply combined with instance discovery should do the trick.

Best regards,
Victor

That's the problem - because NetXMS server do not receive cluster IP addresses from device it cannot identify them as being same device. ipNetToMediaTable is just ARP table - having IP address there does not imply that it is local to the node. Could you please provide MIB files ISILON-MIB and ISILON-TRAP-MIB (documentation says that they can be downloaded from device web UI)? I'll check if cluster addresses can be retrieved from vendor MIB and if yes then problem could be solved by creating custom driver for Isilon devices.

Best regards,
Victor