NetXMS Support Forum

chances are that adding
else
{
  return false;
}
will fix the issue.


In overall you can use
trace(0, "your debug");
PollerTrace("your debug");
to debug what's happeing. First one adds to server log, the latter - to the output of poll messages when you do e.g. Configuration poll from node's context menu.

In NetXMS every agent can operate as a proxy, collecting data from other agents, via SNMP, etc... If your locations have overlapping IP addresses, then you need to use zones. Event if addresses are not overlapping, it's convenient to use zones, as you can set proxies in zone properties and nodes added to this zone will be monitored via there proxies.

Proxies accumulate collected data if there's no connection to central server. Proxies have high availability mechanism - if more then one proxy is configured on a zone, proxies will extablish p2p communication between them to decide which proxy is collecting data.

There's a lot in admin documentation https://netxms.org/documentation/netxms-admin.pdf , but some things may be not yet covered, so feel free to ask questions.

This is actually already fixed, will be included in patch release that is coming soon.

And which database are you using?

Стоит обновиться до 3.9 - если тут найдется какая-то ошибка, то фикс будет делаться уже на 3.9
Или, есть вероятность, что что-то такое уже пофикшено в 3.9

А оно происходит всегда, или редко-рандомно? Если стабильно, то хорошо на время включить 6 уровень дебага на сервере и собрать лог за моменты, перехода через threshold туда и обратно.

What exact netxms version?

Hi!

This was fixed, will be available in next 3.9 patch release.

А это на всех нодах / DCI так происходит, или только на конкретных?
Какая точно версия?

I believe that queue would clear if you restart the server.

In debug console
show threads

might also get some information - what's the load for Discovery and Pollers?

You can try turning on
NetworkDiscovery.EnableParallelProcessing
NetworkDiscovery.MergeDuplicateNodes
this would enable parallel discovery process.
Increasing of ThreadPool.Discovery.MaxSize also might help if parallel processing is enabled.

reporting package named netxms-reporting should be available in the repos

Из NXSL сейчас доступа к этой информации нет - пока что это никому не требовалось. Сделал тикет, когда-нибудь в будущем будет. https://track.radensolutions.com/issue/NX-2095
Сейчас можно сделать табличный DCI или скриптовые DCI. В них данные будут сохраняться в то время, когда есть связь с нодой. И из этого/этих DCI читать данные когда нужно.

А что в списке тревог по этой ноде? Убирается ли оттуда тревога, которая создалась по SYS_THRESHOLD_REACHED?

Hi!

For historical reasons there are two approaches to monitoring windows event logs.
1) Log parser policy in Template. Windows event log is specified in "File path" field prepended by *, e.g. "*System". Parsing is done on agent side. If something matches, agent sends event to server.
This approach allows to specify different templates for different nodes.

2) Windows event log syncronization. https://www.netxms.org/documentation/adminguide/windows-event-log-synchronization.html
This was developed for a customer, who needed to actually store windows event logs centrally. In agent config some filters are specified to include/exclude logs by some parameters. Then logs are sent to server and stored (storing can be omitted by rule(s) in parser).
When logs arrive at the server, they are parsed according to rules specified in "Windows event parser". These rules are global - it's currently not possible to filter by specific nodes/containers, rules work equally for all arriving events. If something matched, event is generated.


Name in Windows parser - just the same code was reused as from policy in template and forgot to hide this field. Name does not affect anything.

Parameters in created events were (or should have been) fixed in some specific netxms version. What exactly version are you using?

Scheduling tasks is currently not possible from NXSL. But should be possible using nxshell, because nxshell allows to do anything what desktop client can. 

So the sequence can be
Object tool that runs NXSL script
NXSL script creates an event
EPP has rule for that event, that runs "execute command on management server" action
the action runs nxshell command

I can prepare the actual nxshell script example a bit later.

Yes, export-import of configuration could be a simpler way. You can not export DCI configuration of a single node, so you have to move DCIs from a node to a template. "Copy to other node(s)" in DCI context menu does the movement to a template. You need to create an empty template first.
Then in Tools->Export configuration you can export your templates.
On the new system you can keep the DCIs in templates and just apply the templates to the nodes you need (it's usually more practical way to have all DCIs in templates). Or you can move the DCIs from template to node(s).