NetXMS Support Forum

Попробуйте поставить Visual C++ 2013 and Visual C++ Redistributable Package
https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package

There's nothing special that NetXMS would be doing when working with the DB - during housekeeping it's issuing these DELETE statement and parallel to that INSERT statements do happen. So it's upon to the database settings how long it's waiting for these statements, until it decides to kill them.
Some information could be found here: https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2005/ms181150(v=sql.90)?redirectedfrom=MSDN

Also - how big is your system and the database?
What's the output of "sh stat" in server console?

Can you show the output of the following queries:
SELECT var_name, var_value FROM config WHERE var_name like 'DefaultDCI%';

SELECT polling_interval, retention_time, count(polling_interval) FROM items GROUP BY polling_interval, retention_time ORDER BY retention_time, polling_interval;

There will be some changes in file upload process in v. 3.4 that should be out within a week. Please check if this problem occurs in 3.4 and give us an update.

With postgres or mysql there's a problem of housekeeping - deleting old datapoints when storage time elapses. This process may create big load on the database, especially if it's big.
For timescale deletion is very optimal - a whole chunk of data for one day is deleted. There are a few sets of chunks - one for "Default" retention time and a few other sets <7 days, 7..30, 30..90, 90..180, >180 days. But the trick is that it's not possible to delete a daily chunk, if it contains data for at least one DCI that retention time has not elapsed yet. As the result, timescale database might take more storage space.
Currently there's an issue when changing DCI retention time - https://track.radensolutions.com/issue/NX-1795

Can you give more details, what exactly you are doing in nxmc when you get disconnected? Does it replicates reliably, or randomly?

You can use DCI with origin "Script". For that you need to create a script in the script library and confgure that script name in properties of a DCI.
Then in the script you can read parameters directly from agent
    $node->readAgentParameter(name)
($node will be the object of node, to which the DCI belongs. You can also use this method on other nodes).

You can also get last collected value of any DCI - https://www.netxms.org/documentation/nxsl-latest/#func-getdcivalue

You can use "abort" operator in the script - if it's called, the script will terminate and no new datapoint will be generated at this time.


Some examples of NXSL scripts are available here: https://wiki.netxms.org/wiki/SG:Script_Examples

Working with VMWare API in in future plans only. It's not implemented yet.

Thanks for sharing

Please try the most recent nxagent-3.3.330 version, adding EnableSSLTrace=yes to agent configuration file and setting DebugLevel=7. Please share agent log for the time when the situation occurs.

You can create action that "executes command on the management server" and call curl in that action.

In current implementation of slack driver it creates a simple json like this:
{"channel":"C061EG9SL","text":"mesage_text"}

so anything you write just goes into "text" field. An ability to generate custom jsons would require to make quite some changes in slack notification channel code.

Can you set DebugLevel=6 in agent configuration file and show agent log during upgrade attempt?

Are you upgrading via GUI, or via https://www.netxms.org/documentation/adminguide/upgrade.html#centralized-agent-upgrade ?
If it's GUI, can you record a video to see at what stage the installation is failing?

libvirt claims that it can connect to vcencter, not only particular ESXi servers.

Here's a video that seems to be explaining how this is done: https://www.youtube.com/watch?v=n3XJ0X1l9DU

libvirt is specified in dependencies of netxms-agent-vmgr, so will get installed automatically when you instal netxms-agent-vmgr package.

Currently there's a bug in the agent that first ssh request since agent start produced that.
You can track resolution of that issue here: https://track.radensolutions.com/issue/NX-1852