NetXMS Support Forum

Some improvements were made in transferring SMTP params to the reporting server - that will be in next patch release. But this should not affect your system, as parameters that you have in your configuration were transferred before these improvements.

Can you share your reporting server log for the moment when it should send the email.
If you are on Linux, this command should show it:
journalctl -u nxreportd

For TSDB data is stored in the following tables - number in the name is the retention period

IDATA_SC_7
IDATA_SC_30
IDATA_SC_90
IDATA_SC_180
IDATA_SC_OTHER
IDATA_SC_DEFAULT

If you DCI retention time is "Default", then IDATA_SC_DEFAULT table will be used.
IDATA_SC_OTHER stores DCIs with duration longer the 180 days.

You can check size of these tables (and also TDATA_SC_* for table DCIs) in your database

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