NetXMS Support Forum

It's a bug in the framework that we use, happens with dark Windows theme. We are working on a fix, but this might take some time. Meanwhile you can try light theme or use web ui.

It would be good if you can collect some debug information. If your server is on Linux:

- install netxms-dbg and gdb packages
- stop netxms server:
systemctl stop netxmsd
- launch it under gdb:
gdb --args netxmsd -D 3

then enter run

when it crashes, enter bt and show us the output

----

Meanwhile, you can use another option to monitor windows event logs - by adding log parser policy to a template and applying that template to your nodes. https://www.netxms.org/documentation/adminguide/log-monitoring.html#file-tag
Chances are that this bug will not appear if using this approach (but may be not)

is it this line?:
    if (b->size == 2) h[b] = b[1];
Try running your script via "Execute script" on your PDU node. You can add line like
    println(b);into your script, this way you'll see what exactly is contained in the variables. I'd start with checking of what comes in variable v, it could be that nothing just comes via snmp. Actually, transport->getValue() can return null if there's some problem, so after that line there should be a check for that:

    if (v == null) return null;

What exactly is version of NetXMS ?

It's quite hard to estimate required resources, as they depend not only on the number of nodes, but also on number of interfaces, number of DCIs per node, data collection interval and storage time, number of scripts, number of various events happening and so on. Also, on big systems use of Timescale DB helps, as it minimizes housekeeper resource usage.

Here are some real-life data about tree installations - X, Y and Z. All are using SSD or NVMe storage. On these systems Postgres (non-timescale) was used, running on the same server, so RAM and core numbers cover both NetXMS and DB engine.

Number of datapoints per second was obtained from the DB by this query: SELECT polling_interval, retention_time, count(polling_interval) FROM items GROUP BY polling_interval, retention_time ORDER BY retention_time, polling_interval;
 

	X	Y	Z
Objects	20554	56040	41542
Monitored nodes	2175	2656	5376
Collectible DCIs	34260	185742	372240
Collected datapoints per second	372	979	2290
Stored datapoints, millions	8995	14978	44195
RAM, GB	24	74	160
CPU cores	8	10	20
DB size, GB	237	1500	1500
Bytes per datapoint	53	108	61

Most probably your DCI became unsupported. If you right-click the list of DCIs, there's "show unsupported" in the context menu. Or you can switch to edit mode - there's pen icon above DCI list.

Check that DCI origin is set to script, check the name of the script. If you right-click your node and choose "execute script", you can run your script there to test if it returns some result. Script parameters, e.g. .1.3.6.1.2.1.1.1.0, activePower can be provided via parameters field.

Hi,

The only thing that MIB files provide is textual decoding of OIDs in MIB explorer. MIBs are not related to templates, you have to create that template yourself.

Да, с библиотеками бывает такое

Для мак можно взять 4.5.3, там в плане UI вроде особо не было отличий

Надо смотреть, какую java берет томкал, сейчас требуется 17-я

Можно запустить из-под gdb и когда упадет сделать bt - может быть там что-то будет видно

This could be done with transformation scripts on a number of SNMP DCIs, but this is not convenient to manage, as transformation script on each of these DCis would be different. 

A cleaner approach would be to use script DCIs. In script library create a script, named e.g. getPduMetric with the following contents:

function main(oid, name) {
  transport = $node->createSNMPTransport();
  if (transport == null) return null;
  v = transport->getValue(oid);

  h = %{};
  for (a : v->split(",")) {
    b = a->split("=");
    if (b->size == 2) h[b] = b[1];
  }

  return h[name];
}
Then create a DCI on the node, origin should be Script. In the metric field we have name of the script with it's parameters:
getPduMetric(.1.3.6.1.2.1.1.1.0, activePower)

Script accepts two parameters - OID and variable name. This way you can have just one script and define everything in metric of your DCIs.

Sure, here's a couple of screenshots. First is log parser policy, file name is *Security which means that it's reading Security windows event log. It's picking only records with ID = 4624. Matching regular expression is .*, we can also use capture groups here, at maximum we can just put (.*), but this will pick the whole multi-line event description. Capture groups, if any, will also go as NetXMS event parameters.

On second screenshot we have event template. Message field describes which event parameters we use to compose the message - it's better to use parameter names instead of %1, %2, as number of parameters may change, e.g. if we add a new capture group, but names will stay the same.

Remember, that you need to apply the template to a node for this to start working.

Try increasing debug level for tag "ldap" by issuing

debug ldap 8

in server debug console (Tools -> Server Debug Console or nxamd -i from command line).
Then issue

ldapsync

command there - it will force the synchronization and check netxmsd log (/var/log/netxmsd)

Ok, so that explains.
If you can provide access to a test device, that would be great (but we would have someone who can work with it after 17-th of March). If providing access is not possible, then we would ask to perform walk for some OID branches.

that means that NetXMS server cannot read LLDP information via standard MIB. Server checks the following OIDs to test if LLDP MIN is supported by device:
1.0.8802.1.1.2.1.3.2.0
1.0.8802.1.1.2.1.3.6.0
1.3.111.2.802.1.1.13.1.3.2.0
You can check with any SNMP walk tool if device responds on any of those OIDs
Also, if you can provide SNMP access to test device, we can test it ourselves adn update server as necessary

It looks that there are problems with the dark theme in the framework that we are using: https://github.com/eclipse-platform/eclipse.platform.ui/issues/246

We will try to add some work-around, but this will take some time.