NetXMS Support Forum

What do you have in Index column in Interfaces tab on the node? Is the index the same or it gets changed? We use the index to identify interfaces on the system, so if a an interface appears with a new index we think that it's a new interface. 

There's a global setting for default expected state - Objects.Interfaces.DefaultExpectedState
Or it can be changed from script - e.g. in configuration poll hook script or interface creation hook script. 

Hi,

Thanks for the feedback (you can also put a star on our github repo )

Yes, right, unsupported, hidden or disabled DCIs may be not shown according to View options. 
The other thing is instance discovery prototypes - they are hidden in view mode, but are visible in Edit mode (pen icon on the toolbar). What settings do you have on Instance Discovery page of the DCI? Pls share screenshot of General and Instance Discovery pages. 

But I am not sure if we have syntax to specify something in brackets after web service name (or was it mentioned somewhere?)

ExternalMetricProvider по идее должен быть нормальным способом запускать что-то периодически. У него тоже есть какой-то таймаут после которого он убивает запущенный процесс, 30 секунд кажется. 

Связь с агентом - по умолчанию агент может поддерживать 32 соединения, можно поднять параметром MaxSessions

Лог агента на 6 или 7 уровне должен подробнее рассказать что происходит в обоих случаях

Have not heard about some existing integration, so you'd need to develop something yourself. Main thing is what exactly you want to synchronize.

From NetXMS side you can talk to NetBox's REST API using NXSL and web services.
Also NetBox supports Webhooks, so may be it can talk to NetXMS REST API

Does this behavior (deletion of interface) happen during scheduled configuration poll, manually called configuration poll or manually called Full configuration poll?

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.