NetXMS Support Forum

Hi,

correct bug tracker link is https://track.radensolutions.com/issue/<issue_id>, for example: https://track.radensolutions.com/issue/NX-1147

Best regards,
Victor

Seems you messed agent and server ports. Please do the following:

1. Stop both server and agent.
2. Delete ListenPort line from both netxmsd.conf and nxagentd.conf
3. Run command
nxdbmgr set ClientListenerPort 4701
4. Start both client and server
5. Check in netxmsd.log that server is listening on port 4701

Best regards,
Victor

Seems you are trying to run two instances of netxmsd at the same time. Try to do the following:

1. Stop NetXMS core service
2. Make sure ports 4701 and 21784 are not listening
3. Run nxdbmgr check and remove lock if asked
4. Edit C:\NetXMS\etc\netxmsd.conf: add line
DebugLevel = 4
and set log file to file (if not set already):
LogFile = C:\NetXMS\log\netxmsd.log
(of course you can set different file name and path).
5. Start NetXMS core service
6. Check log file for startup messages and possible socket errors. You can also post log file here.

Best regards,
Victor

Поллеры переделаны в текущем development бранче. Теперь вместо фиксированого количества потоков - динамический пул, кроме того очередь стала многоуровневой - сервер не пытается параллельно опрашивать один и тот-же агент, запросы к одному агенту сериализаются. Таким образом исключается вариант когда несколько медленно отзывающихся агентов блокируют весь пул. Мы не стали переносить изменение в stable, поскольку изменения большие, и вроде как понятию stable не совсем соответствуют.

Port 4700 is an agent listen port. Seems that server is unable to open port for some reason. Check server log on startup - it should contain messages regarding opening ports. You can run it with debug level 4 for more diagnostic.

Best regards,
Victor

You can use netstat command for that:

netstat -an

and check for port 4701 in LISTEN state.

Best regards,
Victor

Hi,

that seems to be a limitation of libvirt. We are currently considering implementation of Hyper-V monitoring directly without libvirt as it is done already for XEN.

Best regards,
Victor

Hi all!

NetXMS patch release 2.1.2 is out. Changes since previous release:

- Summary tables for table DCIs
- Multi-valued columns in summary tables
- Threshold violation events have current DCI value as parameter 8 (named as "dciValue")
- New agent configuration parameter TunnelKeepaliveInterval
- Optimizations in database access layer
- Improved database check procedure
- Management console:
        - Option to set root object for "Geo Map" dashboard element
        - Filter in geo map view
        - "Duplicate" button in DCI threshold editor
        - Option to show legend for performance tab graphs with single DCI
        - Fixed file upload errors in web UI
        - Option to show "Top N items" in dashboad summary table using given sorting columns
- Fixed issues: NX-1147, NX-1265, NX-1270, NX-1276, NX-1282, NX-1290, NX-1296, NX-1300, NX-1309, NX-1313, NX-1314, NX-1315, NX-1320, NX-1324, NX-1325, NX-1331, NX-1333, NX-1335

Best regards,
Victor

Попробуем сделать. Зарегистрировал в трекере: https://track.radensolutions.com/issue/NX-1337

Hi,

if topology correlation is working, device D should become red, and rest of devices and links blue. Blue in that case means "unknown" - because links and devices could be up actually, but because of failed link NMS cannot determine their status. We probably could add map option to color all unreachable devices and links in red - will discuss that internally.

Best regards,
Victor

Hi,

are you sure "NetXMS Core" service is running? If yes, check that port 4701 is listening and that firewall exception for port 4701 or process netxmsd.exe is set.

Best regards,
Victor

Hi,

server should not remove device from the map just because it's down. But if topology information was removed, then it will disappear. What is discovery protocol used for those devices with wrong locations?

Best regards,
Victor

Hi,

It looks like older agents sometimes send corrupted message which cause server to crash. We fixed server side in 2.1.2 (ignore malformed messages). Upgrading agent to 2.1.1 should also help.

Best regards,
Victor

Hi,

yes, it's possible. You can create two push DCIs and a script. Set this script as an action for your event, extract numbers from message text, and use PushDCIData function to push data into appropriate DCIs.

Best regards,
Victor

 It is internal diagnostic messages meaning that data collection scheduler was not able to work with DCI because it was locked by other part of the system. Most often it happens when DCI is locked because of database update. Other possible reason could be long running transformation scripts.
If you don't experience issues with data collection and don't get "thread not responding" alarms then you can ignore those messages.

Best regards,
Victor