NetXMS Support Forum

Стоит обновиться до 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).

Yes, e.g. for DCI with ID 291 there are consecutive SYS_THRESHOLD_REACHED events without SYS_THRESHOLD_REARMED in between.

Can you show output of the following on your database:
select * from event_cfg where event_name like '%REARM%';
select * from thresholds where item_id = 291;

If you select that threshold last(10)>1000 and click "Edit...", is SYS_THRESHOLD_REARMED event present in "Deactivation event" field?

Check Event Log for that node. Does SYS_THRESHOLD_REARMED event happen?

Could it be that somewhere in rules 1..17 there is a rule that would also react to SYS_THRESHOLD_REARMED?

Checked what we have in log - the line that you would be looking for looks like this
2021.07.19 11:32:30.489 *D* [                   ] Node(OpenWrt.lan)->getMetricFromSNMP(.1.3.6.1.2.1.31.1.1.1.6.3): snmpResult=0
but it's actually debug level 7, not 6 (so would produce event more lines of log).

Probably better approach would be to collect tcpdump on your NetXMS server - you can filter by particular IP address so the dump won't be too big. It wold be good to collect three cases - netxms gets data normally, when DCI goes to unsupported and getting with snmpget.

В свойствах интерфейсов на закладке Polling есть Expected state. По умолчанию он выставляется в то состояние, в котором был интерфейс при его создании. Можно там поставить IGNORE тогда события, что интерфейс ушел в DOWN не должны создаваться.
Массовое изменение можно сделать в hook::ConfigurationPoll скрипте - там нужно будет в цикле проходить по всем интерфейсам ноды.

Или вручную запустить скрипт, который пройдет по всем нодам и по интерфейсам. А для новых интерфейсов, создаваемых в системе добавить обработку в Hook::CreateInterface