NetXMS Support Forum

Did you try
Process.CountEx("EB_BPM.exe",,"z004abcd")
?

Objects.Nodes.ResolveNames - this works only when node is created. 
There's Objects.Nodes.SyncNamesWithDNS, but this one is taking names from DNS only (also not that activating this parameter currently requires server restart which contradicts with what UI is saying - it's a bug)

Hi,

Yes, new Client has cache in ~/.nxmc4 folder. Pls try deleting this folder.

Looks a bit strange... I suggest checking if the actual timer is really running - this can be done in Configuration->Scheduled tasks, you need to enable  "Show system tasks" from the three-dot menu in the upper right corner

Reporthing server uses same configuration as alarm summary emails. However, currently does not send some of parameters configured in notification channel to the reporting server.
Reporting server is using javax.mail.transport to send emails. May be it's possible to configure additional parameters via java params when starting the reporting.

Can you show how you notification channel configuration looks like?

Для скриптового DCI при создании нужно:

поставить Origin = Script
в поле metric написать имя скрипта
ну и Data Type = String

и должно работать. А, единственное, он покажет значение которое в скрипте возвращается оператором return, если там println то их вывод никуда не попадет.

Ну или еще вариант - можно сделать Origin = Internal, metric = Dummy и скрипт поместить в трансформационный скрипт.

Possible results are

Quote

• 0 - Success, connection to target was established and expected response was received.
• 2 - Can not connect to target (connection refused or connection timeout)
• 3 - Invalid / unexpected response from target (e.g. pattern or response-code not matched)
• 4 - Agent internal error
• 5 - Protocol handshake error (e.g. wrong data or no data expected by protocol received, SSL certificate problem)

(https://www.netxms.org/documentation/adminguide/service-monitoring.html#network-service-monitoring-using-dci)

Value of 1 is not described there , but yes, that's bad parameters of the metric

When selecting source objects, you can select several objects at once using Control or Shift buttons. You can select containers - this means that rule will be applicable to all child nodes of that container. Or you may leave Source Objects empty - this would mean any node.

Repeating is easily achieved for DCI thresholds - in threshold configuration there's Repeat event setting. This will generate repeated events and EPP rule would send new notifications.
But there is no setting to repeat SYS_NODE_DOWN event, so we would need to go a bit more advanced way.
You can create a script DCI (or Internal DCI with metric Dummy and have the script in transformation script). The script is

return $node->state & NodeState::Unreachable;
This will return 0 when the node is connected and 1 when node is down, so you can configure threshold and enable event repetition. It won't be a good idea to use SYS_NODE_DOWN event for that threshold as SYS_NODE_DOWN has one set of parameters when it's generated by the system, but events that are generated from threshold have different set of parameters. So recommendation is to create a new event template to be used for that threshold. 

Ok, so most of the requests ended up with timeout. But there's one thing that makes all this a bit complicated. When server talks to the agent there's timeout for this process. By default it is 4 seconds. But these network service checks have timeout of 5 seconds by default, which results in <<ERROR>>.
We've just changed the default timeout for web service checks to 1 second, this will be included in next patch release. Meanwhile you can specify the timeout in the metric, e.g.:

NetworkService.Status(https://mail.customer-mailserver.de, timeout=1000)

Right, favicon is not yet implemented in the new web ui. I've created a ticket for that, you can follow it to know when it's resolved: https://track.radensolutions.com/issue/NX-2777

Hi,

I am not sure about ServiceCheck.HTTPS metric as I do not see it in current docs, may be it's something from earlier versions.
Currently available metrics with some examples are available here: https://www.netxms.org/documentation/adminguide/service-monitoring.html#network-service-monitoring-using-dci

Note that netsvc subagent should be enabled in configuration file of the agent that you use to collect these metrics.

If you face <<ERROR>> you can set DebugLevel=6 in configuration file of the agent. Agent restart is needed for it to have effect. Agent log should have more detailed info about the reasons for the error. Feel free to share your log here

Documentation has an example of how to configure delayed notification and notification when node is back up: https://netxms.org/documentation/adminguide/event-processing.html#actions

Using a DCI for ICMP packet loss can be a way, but it does not cover situations when icmp is not working, but node is still accessible via SNMP or via NetXMS Agent

Great, thanks for the update

NetXMS is running node status poll every minute. If node stops responding SYS_NODE_DOWN event should be generated (the other option is SYS_NODE_UNREACHABLE - if NetXMS detects that loss of communication is due to some other node). So if you need notifications, notification actions in EPP should be configured for these events.

You can check Event Log on a node to see what events were actually generated.

Pls try this version of management client
https://cloud.radensolutions.com/s/ckxq7QQGPqDMzYH