NetXMS Support Forum

In overall it's not recommended to increase Agent.CommandTimeout too much (like > then 5 seconds) because in situations when agents are slow to respond server will spend too much time waiting. 
If your query takes too long, you can use External metric provider - in this case command is executed in the backgound and agent caches values. https://netxms.org/documentation/adminguide/agent-management.html#externalmetricprovider

This means that something is configured incorrectly in the DCI. 
Is Origin set correctly? Anything in transformation script?

What if you try to read value of that metric using nxget?

You should paste it into the "Source". Then click "Execute" button on the toolbar (or F9 key on the keyboard) and it should produce some output in "Output".

Процесс запуска через gdb такой:

убедиться, что в системе установлен пакет netxms-dbg

gdb /usr/bin/netxmsd

run -D

Дождаться креша процесса, потом дать команды:
bt
kill
quit

Yes, right, that's "execute server script" from the menu that opens on the right-click on the device

Please do "Execute script" from context menu of the node and run the following:

for (p : $object.parents) println(classof(p), p.name .. " (" .. p.id .. ")" );

It will output all containers and subnets where this node is present along with their IDs in brackets. You can use this ID to search under Entire network by entering #123 in the filter (replace 123 with actual id)

On any node under Infrastructure Services there's Data Collection tab. The screenshots are from properties of a Data Collection Item (DCI) from that tab.

DCIs can be specified on nodes, or in template (which should be applied to nodes). You can create your DCIs on a node to test them and move to a template later on.

We have some info on data collection in the docs: https://netxms.org/documentation/adminguide/data-collection.html , but feel free to ask questions. 

Simple syslog parser rule with Matching regular expression .*  and specifying the event will work. They you can add Facility and Severity filters if needed.

If I understand correctly, you want to start a GUI app within a Windows user session. 

We don't have a ready mechanism for that. There are two components of NetXMS agent - session agent and user support application which run in user sessions - they can take screenshots and the latter can also show notifications to user - may be this can cover your needs.

Otherwise - main agent process can execute commands specified in nxagentd.conf (https://netxms.org/documentation/adminguide/agent-management.html#agent-actions), so you can use some 3-rd party app that would allow to start application in user session, but I can not recommend any apps for that.

In syslog parser we can configure event generation. You can create some event template for this and uncheck "write to log" as we use that event just to pass information.

Next step is to have EPP rule. In this rule we can specify container with the clocks, so that rule reacts only to messages from them. Here we need some scripting, e.g.:
$node.setCustomAttribute("lastSyslogMessageTimestamp", GetCurrentTime());
return true; // To process actions in the rule if we need themThis will store timestamp into custom attribute on the node. We can access parameters of the event, e.g. $event.getParameter("message") will be the message, so you can filter by that in the script if needed.

Now on the node we can create a script DCI or Internal DCI with Dummy metric and to things in it's transformation script:
return GetCurrentTime() - $node.setCustomAttribute("lastSyslogMessageTimestamp");So our DCI keeps number of seconds since last syslog message. You can set units to Uptime to display the value in human-readable form. Threshold would compare with the number of seconds that you need.


P.S. We also can push value to a push DCI from EPP rule's script:
dciId = FindDCIByName($node, "lastMessageTimestamp");
if (dciId != null) {
  PushDCIData($node, dciId, GetCurrentTime());
}but the problem is that threshold on a DCI is processed only when new value is coming, so for that we need some DCI that is regularly collected.

Yes, because netxms-dbg by default wanted to install 5.1.4, but since versions of all packages have to be the same, it pulled newer version of all netxms packages. There's a way to tell apt-get to install specific version of a package.

On Events.Processor.PoolSize - it's actually limited by 128 and depends on what you have in Events.Processor.QueueSelector - by default it is %z so that events from each zone go to a separate queue. So if you have just one zone, then it's still everything in one queue. Using something else for queue selector might be dangerous. In overall, except if you system is really huge, it should be enough with one event processor, but EPP rules should not take long time to do their job.

So, what's happening on your system - you have some epp rule which calls an action (which probably sends a notification). Preparation of text for this action calls a script via %[script_name] macro. And the thing is that while this script is running, this blocks further EPP processing. And you have some script that is talking to some API. I've sent some more details in PM.

Once the text is prepared, subsequent processing of this action is detached from EPP processing and not blocking anything.

So what you can improve:


- instead of notification sending action you can have script action and in that script you can talk to API and do SendNotification() - this won't delay EPP processing.

- depending on what this API is doing, may be you can have  a scheduled task for nxsl script that would pull data, parse it (nxsl has support for json parsing) and stores data in persistent storage or custom attributes of some object. Then it would be faster to get data from there.

- When calling web service from script there's acceptCached parameter that can speed up operations with a web api: https://netxms.org/documentation/nxsl-latest/#_instance_methods_17

Pls try to delete the subnet object (make sure that you nodes are also present in some container so that they are not getting deleted).

Then on conf poll subnet should be recreated again - check if the bug persists then.

Currently server is not using information about wireless clients to build maps. But this seems to be good idea, I've logged a ticker, you can follow it to know when this gets implemented. https://track.radensolutions.com/issue/NX-2724

Карты строятся по информации о пирах сетевых интерфейсов. Если на ноде зайти на закладку Interfaces и проскроллить эту табличку вправо, там будет колонка Peer Node.

Информация о Wi-Fi клиентах сейчас при построении карты не учитывается. Но инфа о клиентах есть - ее видно на точках доступа на закладке Wireless Stations. В принципе это неплохая идея уметь показывать их на картах, я сделал тикет, когда-нибудь сделаем. https://track.radensolutions.com/issue/NX-2724