NetXMS Support Forum

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.

Hi!

By filtering the was as it's in alarms do you mean filtering by entering text in filter field or sorting by clicking on the column headers.

Problem with filtering of table DCI is described in this issue: https://track.radensolutions.com/issue/NX-1871
There are plans to have some out-of-the-box DCI grouping mechanism, issue for this is here: https://track.radensolutions.com/issue/NX-777

Several options:
1) Script threshold. In that script you can use GetDCIValues() to get values for some period, e.g. 10 minutes 1 or 2 days ago. Get average for that period and compare it with the current. It's possible that there were collection issues and GetDCIValues() will not return anything - script should check for that.

2) Get some baseline initially and store it in a custom attribute. The custom attribute name should be like signal_level::GigabitEthernet1/0/1 - so some text::instance name.
The value can be stored in transformation script by checking if such custom attribute exists.

Then in the threshold you can use %{custom_attribute:default_value} macro. This macro has a special behavior (not yet documented) - first of all it will try to find custom attribute named "custom_attribute::instance", where instance is the instance name from DCI properties.
If not found, it will try custom attribute with "custom_attribute" name, if that is not found, will take the default_value, if it's given.

Current implementation does not support adding XML to events. I've created an issue to add this:
https://track.radensolutions.com/issue/NX-2072
also there's no exact plan when this could be implemented.

This has been implemented in developers version and will be released soon.

DCI properties have two places where multiplier mode is set - in "performance tab" and "other options".

It could be necessary to reload Last values tab for that settings to have effect.

I've just tried in Last Values - it looks to be working for me.