NetXMS Support Forum

Hi,

The templates I provided were for NetXMS 2 and they are meant to only apply to nodes to which they apply.
However, I haven't updated them for version 3 yet which is an issue, as they all rely on flag fields which changed in version 3.

You can always disable the auto-apply rules (which is the part that controls automatic assignment) in the templates and manually bind nodes to them though.

Cheers

I don't think you can change an event source after that event is received.
As you indicated, you can create a new event and set the correct source for that new event though.
To avoid your database doubling in size, you could run a regular cronjob/scheduled task to clean out the duplicates.

Or you could use a cronjob/scheduled task to adjust the source directly inside the database at regular intervals. That wouldn't be live though.
Or setup a trigger in the database to automatically perform that task in certain cases. Not sure about the performance impact on such a step though.

Edit: Or simply use the inbuilt and smart way of doing it, which Victor mentioned below. 

If the same event on the same device triggers the same Alarm key, then the counter should increase rather than a second alarm being created.
The Alarm key is set as part of the Event Processing Policy.

You can also check the Alarm Log (not the Alarm Browser) to see the exact Keys for the two alarms in your screenshot, which might help you in determining where things are going wrong.

Being able to detect the switches with Layer 2 protocols like LLDP or CDP does not mean NetXMS can connect to them using SNMP.

If you wish to poll SNMP data on the Microtik switches, the NetXMS server (or a proxy) needs to be able to access the switches IP addresses via SNMP. That means routing must work and any firewall in between must allow that traffic. If you do not want to allow any traffic from your computer into your management network, you can place a single system into the management network, install a NetXMS agent and have it connect back to the NetXMS server using Agent Tunnels, which means the connection will be established from the management network outbound, not the other way around. That system can then be your proxy for the management network and poll all the switches.

However, if all you care about is the data presented to you by using LLDP or CDP, you can create an ExternalParameter on a computer of your choice to run those tools and format the data so that NetXMS can read it.

For searches like that, I manually open the Syslog window and add my constraints before searching.
That's for the same reason you mentioned: if you don't, it will go through the entire syslog table (even if it only returns the latest 4000 lines or something like that).
A default to limit Syslog (and SNMP Trap and Event Log) output to anything newer than a configurable (Server Side? Client Side? Both?) interval would be a huge improvement for that.

I'd suggest doing away with statically configured DCIs for disk space and replacing them with Instance Discovery ones, which will pick up any volume in your system for monitoring purposes without you having to hardcode any of them. There is documentation on that topic and there are quite a few examples on the forum on that topic, so a quick search should yield some results.

Quote from: Victor Kirhenshtein on September 18, 2019, 09:54:26 PM
- Regexp matching operation in NXSL returns array of capture groups on success

The above is currently causing issues if you have logical operators combined with regular expressions in statements like the following:
if ( ( $node->snmpOID ~= "^\.1\.3\.6\.1\.4\.1\.1991\..*" ) && ( $node->snmpOID != ".1.3.6.1.4.1.1991.1.3.52.2.4.1.1" ) ) return true;
This will fail with an error "Condition value is not a number".

If you have scripts with if statements utilising regular expressions and logical operators together, you should wait for a patched version (which is being worked on already).

From what I've seen after some basic testing, it loads a tray icon on the computer in question and allows the user to execute commands as pre-defined on the NetXMS server.
It's not like VNC, i.e. it's not a remote control tool.

Quote from: tomaskir on September 12, 2019, 02:36:19 AM

Quote from: Tursiops on September 12, 2019, 02:16:29 AM
Just a practical note on this one:

Quote1. We have switched from TRE to PCRE as regular expression engine. In most cases this should go unnoticed, but in certain cases regular expressions may stop working or produce unexpected results.

A side effect of this change is that if you are matching a regular expression, even without a capture group, $1, $2, etc. will be reset to null values.
An transform script example of where that might cause an issue:

Code Select Expand

if ( $1 ~= "^Hello\s+World" ) {
  return $1;
} else {
  return "Something Else";
}

In prior versions of NetXMS, if the DCI returned "Hello World", the transform script would have returned exactly that.
With version 3, the transform script will return null.

You will need to change your script to something like this:

Code Select Expand

value = $1;
if ( value ~= "^Hello\s+World" ) {
  return value;
} else {
  return "Something Else";
}

Is this a known and expected change or a bug?
This will break A LOT of my NXSL scripts...

That was an expected change at the time (we were running the beta) and broke several scripts in our system, hence I thought I'd point this out by giving an example.
I'd recommend going through the scripts prior to upgrading.

Quote from: normalcy on September 12, 2019, 03:34:03 AM
In the console, when deploying agent packages with the package manager I'm getting an error status "failed" "Agent's version doesn't match package version after upgrade".

The 3.0 agents seem to be installed on the clients and look to be working (polls work and send back 3.0 agent version) but summary tables show 3.0-2258-gc5516133f2 agent verison, would that be cause of error if 'package version' is something like 3.0-2258 only?

Yes, that is correct.
The next agent release is going to fix that. The hash shouldn't be in the version name anymore.
Alternatively, you can remove the package from package manager, edit your NPI file and re-import it.
In the NPI file, change the "VERSION" line to match the one you're seeing on the agents right now. That way when NetXMS checks post-upgrade, it will find that the version matches what it expects to see.

Thanks to the team for all the effort put into this. Great Release!


Just a practical note on this one:

Quote1. We have switched from TRE to PCRE as regular expression engine. In most cases this should go unnoticed, but in certain cases regular expressions may stop working or produce unexpected results.

A side effect of this change is that if you are matching a regular expression, even without a capture group, $1, $2, etc. will be reset to null values.
An transform script example of where that might cause an issue:
if ( $1 ~= "^Hello\s+World" ) {
  return $1;
} else {
  return "Something Else";
}

In prior versions of NetXMS, if the DCI returned "Hello World", the transform script would have returned exactly that.
With version 3, the transform script will return null.

You will need to change your script to something like this:
value = $1;
if ( value ~= "^Hello\s+World" ) {
  return value;
} else {
  return "Something Else";
}

Unless you are looking for a very specific instance, you will want to use Instance Discovery.
In which case you'd configure your DCI using something like FileSystem.FreePerc({instance}) and under Instance Discovery you'd select Agent List as Instance discovery method followed by entering FileSystem.MountPoints as List name.
You can get a list of available agent lists by right-clicking on a node and selecting (I think) Info->Supported Lists. We've changed our menu structure, so not sure what the default is.
For your Hardware.Processor.Family(*), I'd guess the list to use is "Hardware.Processors" (taken from the supported lists on one of my agents).

The whole idea of Instance Discovery is that you don't need to enter every item manually. Nor do you have to worry about what happens when something changes, Instance Discovery runs regularly and will pick new items up and remove old ones (you can configure how long you want to keep the data once an item is no longer found).

Your script works fine for me. For testing purposes I created a DCI from it and it works, too.
Could you show your DCI configuration?

I'm assuming you placed the script into your script library, created a DCI with a "Script" Origin and provided your script name as Parameter and Data Type is Integer?

I just double-checked on one of our servers and can confirm that at least Windows 2016 isn't using the ifX table (which you are trying to query). Considering SNMP on Windows has been deprecated for a while now, I wouldn't expect that to change. That also means using SNMP is probably not the best way to get this data from a Windows system in general.
For the ifTable, you'd want to query .1.3.6.1.2.1.2.2.1.10 for inbound and .1.3.6.1.2.1.2.2.1.16 for outbound. Again, I would not recommend doing this on busy Gigabit or faster connections as counters are going to overflow every few minutes and you won't be able to trust the data you're receiving.

There are two ways to setup Agents.
The original way is for the NetXMS server to connect to the client. This doesn't require any certificates at all, just a port forward for TCP 4700. If you only have one agent at the other end, this will work just fine for you.
The other way are Agent Tunnels, in which case the Agent will connect to the NetXMS server. This one requires certificates on the server (the server will then generate certificates for the clients as needed). There are some guides available on the forum and at least on Linux it looks more complicated than it really is.

We are running on Linux and we are not actually using Actions in this particular way, so can't confirm the path myself.
If the service is running as SYSTEM, I'd guess that you might end up in C:\Windows\System32 by default, so I'd probably try full path first?