NetXMS Support Forum

Not sure, if that approach would suit your situation, but here's an alternative

DCI object has attribute lastPollTime. That's the time stamp of last time that DCI got data. You can read this value in transformation script of your "primary" DCI. When delayed data would be coming to the server, this attribute will show correct timestamp of each incoming datapoint.

The idea is that you can configure your "secondary" DCIs as push DCIs. And implement the logic in the transformation script of the "primary" DCI.

E.g. if a new hour has started, you can calculate the average of the "primary" DCI and push it to the "secondary". Some more logic requred to do it only once - you can use a custom attribute and store last time there.

Can you also show the screenshot of configuration of this DCI - first page - "General"

Thank you for reporting.
The ThreadPool DCIs are failing because you have only one SYNCER process configured (default setting) - in this case thread pool mechanisms are not used.
Server.Heap ones work only if server was compilled with jemalloc.

In coming 3.3. version out of the box templates were updated to fix these issues.

First parameter of CountEx should be process name which is actually "node".
Try something like this:
Process.CountEx("node", "\/kibana\/")

The thing is that the .bat file is not an executable as such, it's being executed by cmd.exe. And ExternalParameter needs an actual executable.
Running cmd.exe /C <your_bat_file> should probably to the job.

No such functionality is currently implemented. It could be a valid approach, but such averages tend to look differently then original data - e.g. spikes are smoothed. It could be possible to keep 3 values - min, max and average, but then it complicated the system and requires more development effort.
Since storage is quire cheap these days, a simpler approach is just to store more data - with Postgres time scale DB it's possible to delete old data with minimal load onto the database.

There is Process.CountEx() metric, that should allow to filter processes by the command line that was used to launch them.
https://www.netxms.org/documentation/adminguide/appendix.html#process-countex

You can find the command line by running
px fax

Filtering is done with the help of regular expression. You can test your regular expression here: https://regex101.com/

ExternalParameter is able to search in path, but requires exact executable name with extension. On the contrary, ExternalParameterShellExec calls shell and shell is able to find an executable even without extension (but I am not sure, if it is present in 1.0.13).

nxagentd.service is the file name for systemd scripts, not the name of actual process. The process name is visible in command like top, ps, for netxms agent it's nxagentd.

In your log the error usually happens 1s after the connection is created, but there is one place, where it happens just few ms afterwards:
2020.04.09 13:34:04.722 *D* [                   ] SSH: created new session [email protected]:22/1
2020.04.09 13:34:05.828 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)
--
2020.04.09 13:34:12.345 *D* [                   ] SSH: acquired existing session [email protected]:22/1
2020.04.09 13:34:13.366 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)
--
2020.04.09 13:34:19.436 *D* [                   ] SSH: acquired existing session [email protected]:22/1
2020.04.09 13:34:19.456 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)
--
2020.04.09 13:34:30.496 *D* [                   ] SSH: acquired existing session [email protected]:22/1
2020.04.09 13:34:31.517 *D* [comm.cs.1          ] GetListValue(): result is 500 (INTERNAL_ERROR)


Do you see anything that would correspond to these events in  /var/log/auth.log  on the Raspberry?
Can you take a tcpdump to see, if the connection is established at all when this happens?

Изображения загружаются через Configuration -> Image library. Там в контекстном меню есть пункт загрузки изображений, там же будут видны поддерживаемые форматы. Сейчас на карте используется размер 48х48, изображения большего размера могут отрисовываться некорректно.

Hi,

there has not been any changes since 2.2.2 that could make such dramatic change in launch time.
I would suggest to try running nxshell on a different system, preferrably clean installed to see if it makes any difference.

I believe it should be possible to make jython program that starts, connects to the api and has some sort of interprocess communication to know what commands to run.

There's a new release available not that fixes one memory leak. Please try it.

AgentTunnels.UnboundTunnelTimeoutAction defines what happens when unbound tunnel connects to the server. When it connects, server puts it into a list and does nothing. This allows to perform a manual action. Then, after a timeout (it's configurable, I think it's 1 hour by default) server performs an action
- bind to existing node - if there is an appropriate node, tunnel will be bond to it. If not, the tunnel will stay unbound.
- bind to existing or create - if no appropriate node, it will be created
- there's also option to drop tunnel - in that case agent will reconnect and after mentioned timeout process will repeat.

It depends on what you want to achieve.

If you are not interested in these interfaces at all, you can prevent them from creating - modify script "Hook::CreateInterface" in scripting library. Script is executed on configuration poll for each new interface (accessible as $1, https://www.netxms.org/documentation/nxsl-latest/#class-interface) and should return true or false. If return value is false - interface will not be created.

It's possible to use $1->ifType (interface type as defined by IANA, list of interface types available here: https://github.com/netxms/netxms/blob/master/include/nms_common.h#L908, or can be seen on the object overview tab when interface is selected).
Or you can query node via SNMP to get some data.

If you want to keep interfaces in the system, but ignore status change - simplest way is to set "Expected Interface State" to IGNORE. You can do it in configuration poll hook (Hook::ConfigurationPoll).
Sample:

for (i : $node->interfaces) {
    if (i->ifType == 131) { // tunnel
        i->setExpectedState("IGNORE");
    }
}

If you want to block events in the EPP, add rule before any alarms or notifications:
Script:
    i = $node->getInterface($5);
    if (i->ifType == 131) { // or any other filter
        return true;
    }
    return false;
Action:
    stop processing

Alternatively, add script to your alarm / notification rules and return true only if it's not dynamic interface:
    i = $node->getInterface($5);
    if (i->ifType == 131) { // or any other filter
        return true;
    }
    return false;