NetXMS Forum

Possible case could be a locking of some server thread. You can capture server threads when you see delays in working with the server from the GUI, here's the script: https://github.com/netxms/netxms/blob/master/tools/capture_netxmsd_threads.sh Script should be executed 3 times with 20-30 second interval. It needs gdb and netxms-dbg packages installed on the system. Also to check - on netxms server node there should be Server: Number of Processed Events (based on internal Server.TotalEventsProcessed metric) - just to verify that there we no sudden spikes in event quantity. In overall there's quite a few metrics there, e.g. Server QueueSize ones, it's worth checking them for any big spikes. If you don't have Server.ImportConfigurationOnStartup set to Always, you might not have the most recent template with above mentioned DCIs, you may want to import them from /usr/share/netxms/templates/netxms_server.xml

Not sure about the absent interface.name - possibly a version issue? I've attached screenshots of an example similar to your approach. It worked for me on server version 5.2.x (Debian) against a 6-port MikroTik. [image: Port speed template - 1 - General.png] [image: Port speed template - 2 - Instance Discovery.png] [image: Port speed template - 3 - Data Collection.png]

Quite a few of these cameras were added to NetXMS when they were already offline. They then all polled down as they were checking for SNMP. I terminated the first alarms as I knew they didn't have SNMP functionality, but I have been unable to get them to change status based on ICMP either. They have also been offline since addition so I figure that would be why their status is not changing.

Thanks Victor - that did it!

Thanks Amay! My problem was that I didn't realize that the last digit was the index for the interface that I wanted to monitor. I can pull proper results for the individual DCI. I just need to figure out how to setup a template to automatically pull these values.

You can set debug level to 6 on agent, where requests should go through and check agent log. There should be messages like:  2024.07.22 16:44:06.575 *D* [comm.cs.1250      ] Requesting metric "NetworkService.Status(https://netxms.org)" 2024.07.22 16:44:06.995 *D* [netsvc            ] NetworkServiceStatus_HTTP(https://netxms.org got reply (807 bytes, response code 302)

This works beautifully. Thanks so much, Filipp!

Here are the DCI settings that work for me. I also include 'return format($1/10, 1, 1);' in the Transformation section, to convert the 1/10ths integer value. Of course, you'll only get a result if the MikroTik model reports a 'temperature' value under '/system/health'. Cheers. [image: RouterOS - System Amb Temp - General.png] [image: RouterOS - System Amb Temp - Instance Discovery.png]

Normally it should happen automatically for events SYS_NODE_DOWN if topology is known to the server. If server is able to determine route from itself to unreachable node, it will check all intermediate nodes, and generate SYS_NODE_DOWN only for router closest to the server, and SYS_NODE_UNREACHABLE for nodes down the line. For more complex logic you can use script filters - all kind of topology information is available in scripts, so you can filter events based on peer nodes, routing information, etc. Best regards, Victor

It works beautifully now. Thank you so much, Filipp!