NetXMS Support Forum

Yes, export-import of configuration could be a simpler way. You can not export DCI configuration of a single node, so you have to move DCIs from a node to a template. "Copy to other node(s)" in DCI context menu does the movement to a template. You need to create an empty template first.
Then in Tools->Export configuration you can export your templates.
On the new system you can keep the DCIs in templates and just apply the templates to the nodes you need (it's usually more practical way to have all DCIs in templates). Or you can move the DCIs from template to node(s).

Yes, e.g. for DCI with ID 291 there are consecutive SYS_THRESHOLD_REACHED events without SYS_THRESHOLD_REARMED in between.

Can you show output of the following on your database:
select * from event_cfg where event_name like '%REARM%';
select * from thresholds where item_id = 291;

If you select that threshold last(10)>1000 and click "Edit...", is SYS_THRESHOLD_REARMED event present in "Deactivation event" field?

Check Event Log for that node. Does SYS_THRESHOLD_REARMED event happen?

Could it be that somewhere in rules 1..17 there is a rule that would also react to SYS_THRESHOLD_REARMED?

Checked what we have in log - the line that you would be looking for looks like this
2021.07.19 11:32:30.489 *D* [                   ] Node(OpenWrt.lan)->getMetricFromSNMP(.1.3.6.1.2.1.31.1.1.1.6.3): snmpResult=0
but it's actually debug level 7, not 6 (so would produce event more lines of log).

Probably better approach would be to collect tcpdump on your NetXMS server - you can filter by particular IP address so the dump won't be too big. It wold be good to collect three cases - netxms gets data normally, when DCI goes to unsupported and getting with snmpget.

В свойствах интерфейсов на закладке Polling есть Expected state. По умолчанию он выставляется в то состояние, в котором был интерфейс при его создании. Можно там поставить IGNORE тогда события, что интерфейс ушел в DOWN не должны создаваться.
Массовое изменение можно сделать в hook::ConfigurationPoll скрипте - там нужно будет в цикле проходить по всем интерфейсам ноды.

Или вручную запустить скрипт, который пройдет по всем нодам и по интерфейсам. А для новых интерфейсов, создаваемых в системе добавить обработку в Hook::CreateInterface

Just tried this
- created a DCI, type: Internal, parameter: Dummy(ip), data type: string, transformation script: return $node->ipAddr;
- checked in last values that this DCI actually collects the IP address
- created summary table, added column named IP addr, DCI name: Dummy(ip)

so there's no need for an OID - DCIs are identified by parameter and parameter in this case is "Dummy(ip)"

What exactly version of NetXMS are you using? Are you collecting directly, or via NetXMS proxy?

Can you try setting debug level 6 for a moment and do manual poll of that DCI? On the server you can change debug level on the fly in Tools -> Server console by issuing e.g.
debug 6

The processing has several steps:
- trap arrives
- event generated
- event processed by EPP and some actions are executed.

It's important to understand on what stage the delay are. Can you check timestamps in snmp trap log, event log and alarm log to see where it's delaying?

Also, there's a built-in template for netxms server performance monitoring. If you upgraded from previous versions, that template does not get upgraded automatically (you need to change ImportConfigurationOnStartup server configuration parameter and restart the server, or you can take /share/netxms/templates/netxms_server.xml file from the file system of the server and import it using web/desktop client.

No, currently not. You need to use for email forwarder like postfix.

Let's try to exclude the option that transformation scripts get randomly delayed. Try wrapping transformation scripts in something like
trace(0, $object->id . ":" . $dci->id . " tranformation script start");
...
trace(0, $object->id . ":" . $dci->id . " tranformation script end");

first parameter of trace() defines the log level. This way you should get some stats on the actual duration of the transformation scripts.

You can use nxdbmgr for database migration
nxdbmgr migrate conf_file_with_config_for_connection_to_old_database.conf

there are several parameters to skip collected data and logs, to exclude most add following to the above command
-s -Z alarm -Z audit -Z event -Z snmptrap -Z syslog -Z winevent

Collection of server log would be beneficial here. Can you set debug level 6 for client.* tag (issue "debug client.* 6" in Tools->Server Console or you can set this in server configuration file).
nxpush is creating the same connection as nxmc, so sessions of both will be visible under this tag. Each new connecting gets a new session id which is visible in the debug tag, e.g. client.session.1234.

Then, when you encounter a nxpush nang, you should be able to find and grep out a corresponding session from the log file.

There's out of the box template for server monitoring which has a number of DCIs for queue and thread wait time monitoring. If you were upgrading from previous version this may not have imported, unless ImportConfigurationOnStartup server configuration parameter is set to "Always".
You can just take this template file from server file system and import it via nxmc - it's here: share/netxms/templates/netxms_server.xml

Monitoring of database is also a good thing. If you use Postgres, there is subagent for it which provides a number of parameters that could be useful.

I'd probably just use some big number for default value like %{signal_min:999999999}
Also you can use hook scripts to add some default value for custom attribute on node creation or configuration poll if attribute is not present yet.

Another option could be to create push DCIs use PushDCIData(). You can e.g. do this from a transormation script of of another DCI.