NetXMS Support Forum

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

Hi,

you can also use nxalarm command line tool for acknowledge and terminate alarms.

Best regards,
Victor

Hi,

you can open dashboard automatically maximized within workspace, but menu bar will still be there. It is possible with desktop client though. See this document for possible command line options: https://wiki.netxms.org/wiki/Autologin_for_Management_Console.

Best regards,
Victor

Do those nodes respond to SNMP or only send traps? If interface list can be read then theoretically NetXMS server should match discovered node to existing one by MAC address.
Also, nodes discovered via traps pass through same discovery filter script, so you may do additional filtering here - for example, get DNS name from IP address and check if it is name of existing node. If your DNS is consistent that should prevent duplicate creation.

Best regards,
Victor

Hi,

did you check what events were processed during spike? That can gave an idea where to look. Also, do you have filter scripts in your event processing policy?

Best regards,
Victor

What version you are using?