NetXMS Support Forum

Hi all!

NetXMS 3.4 patch release 2 is published. Changes since previous release:

- PostgreSQL monitoring subagent
- Improved driver for Cisco Nexus
- Improved LLDP based network topology discovery
- Correctly detect LLDP capability on Mikrotik devices
- New NXSL functions GetServerNode and GetServerNodeId
- New NXSL function SendMail
- Fixed UI bug with accessing collected performance data from data collection editor
- Configurable size of SNMP proxy thread pool on agent
- Housekeeper optimization
- Added drivers for Cambium Networks devices (ePMP and cnPilot)
- Fixed issues:
        NX-1863 (Logwatch fails on parsing large Windows Event Log events)
        NX-1880 (Duplicate links on automatic maps with multiple seed nodes)
        NX-1895 (After server restart GUI is not showing from where a custom attribute is inherited)
        NX-1897 (ReadPersistentStorage returns incorrect value for non-existing key)
        NX-1901 (Get node of active NetXMS server in NXSL)
        NX-1910 (Spelling mistakes in Java API)

There were no changes in agents besides WIndows, so agent packages were not updated and 3.4.232 still good to use.

Best regards,
Victor

Да, получится. Серверу мониторинга нужен доступ по SNMP ко всем устройствам, а дальше собственно карты строятся на основе собранных данных. Для карт второго уровня это LLDP, CDP, таблицы MAC адресов, и т.д. Для карт IP уровня это сетевые интерфейсы и их адреса.

Hi,

pay attention to case - it is modifyObject, not modifyobject.

Best regards,
Victor

Возможно на сервере отключена прямая отсылка сообщений? Проверьте параметр сервера AllowDirectNotifications - должен быть включен.

I think it should be implemented as notification channel, but it is not a high priority currently, as there is a relatively easy workaround.

Best regards,
Victor

Script should find another alarm that is a root cause for current alarm. Script is expected to either return null (means no root cause) or alarm object. If root cause alarm is returned for current alarm then current alarm will be placed under root cause in alarm browser (so you'll see alarm as hierarchy instead of flat list). Acknowledging or terminating root alarm will also do the same to all sub-alarms.

Best regards,
Victor

It was caused by a bug in DB init script (wrong primary key). We have fixed it, fix will be included into next patch release.

Best regards,
Victor

That sounds useful, I've registered it as feature request (https://track.radensolutions.com/issue/NX-1911).

Best regards,
Victor

Yes, persistent storage (or custom attribute on a node) that holds timestamp of last SYS_NODE_DOWN would be best solution.

Best regards,
Victor

Hi,

could be database issue or time zone issue. In database you should have table idata_nnn, where nnn is actual node object ID. Check if you have any records in that table. If yes, check that time on your server is correct and that time zone is correct as well. Internally server and client uses UTC timestamps, so even when time looks identical it may in fact be incorrect on one side when concerted to UTC. If there are no records in idata table then likely there is issue with storing data to database - in that case check server log for SQL errors.

Best regards,
Victor

Hi,

looks like reading from DB take very long time - which is quite strange if you have only 15 nodes. Please set server debug level to 6, repeat the problem, and provide server log file for that time.

Best regards,
Victor

Hi,

looks like wrong primary key was set during PostgreSQL DB init. What NetXMS version you are using?

Best regards,
Victor

Hi,

names on maps are the same as object names. You cannot have separate "map" name. However, you can rename your nodes automatically to include location information using configuration poll hook. For example, you can have hook script as this:


if (($node->snmpSysLocation != "") and not ($node->name like "*" . $node->snmpSysLocation))
   $node->rename($node->name . " " . $node->snmpSysLocation);


This script checks that node name is not already ended with location string and it is not empty, and then appends location string to node name. You may need to introduce more sophisticated logic if sysLocation can change over time and you'll need to replace old location with new one and not simply append new location.

Best regards,
Victor

Hi,

upgrade to version 3.3 or 3.4, it will renew expiring certificates automatically before expiration date.

Best regards,
Victor

Now it makes sense I think PostgreSQL.Replication.WALSenders will be the best name then.

Best regards,
Victor