NetXMS Support Forum

Grafana definitely can be used as publishing front end for customers as you can have completely separate access control.

Best regards,
Victor

I suspect that compiler shipped with CentOS 6 may be too old. My recommendation is to upgrade platform to CentOS 7.

Best regards,
Victor

You initialize variable activeDCIs to 1, which gives you incorrect result - if you have 36 cores line

activeDCIs++;

will be execured 36 times and result will be 37.

Best regards,
Victor

Did you clone it from our repository? Because latest version still waiting for approval to get into official Grafana plugin list.

Best regards,
Victor

Quote from: Egert143 on September 16, 2019, 02:03:33 PM
When i use "if (dci->name like "*{instance}") continue;" it doesent match.

Please share full script code. I checked on my system and it works as expected.

Best regards,
Victor

You can do something like

for (dci : FindAllDCIs($node, ".1.3.6.1.2.1.25.3.3.1.2.*"))
{
   if (dci->name like "*{instance}")
      continue;
   // your code here
}


Best regards,
Victor

Hi,

you have to manually install newer libpcre and configure it with libpcre32 enabled. You can use this version: https://ftp.pcre.org/pub/pcre/pcre-8.43.tar.gz and configure it as following:

./configure --prefix=/opt/pcre --disable-static --disable-dependency-tracking --enable-pcre16 --enable-pcre32 --disable-cpp --enable-utf --enable-unicode-properties --disable-stack-for-recursion

It will install correct pcre into /opt/pcre (you can choose different prefix of course). Then add option --with-pcre=/opt/pcre to NetXMS configure.

Best regards,
Victor

Зарегистрировал как баг (https://track.radensolutions.com/issue/NX-1676), попробуем повторить у себя.

Hi,

yes, script is valid, but you have to remember that it search DCIs by name (parameter name). Are you sure you have parameter names Cpu 1, etc. and not DCI descriptions?

Best regards,
Victor

Hi,

there are issues with libraries needed by 3.0 in Debian Jessie and so far we have no plans to provide Debian Jessie packages for version 3.0.

Best regards,
Victor

Hi,

I've found bug in Windows installer. Try to rename directory C:\NetXMS\lib\ncd to C:\NetXMS\lib\ncdrv and restart NetXMS Core service.

Best regards,
Victor

Sorry, I was distracted by reflective access warnings and didn't notice actual method name. It was renamed to getAllChildren. We will upload javadocs for 2.2.17 and 3.0 in next few days.

Best regards,
Victor

Hi,

everything is correct. Raw value is in bytes, so if you want it in bits it should be multiplied by 8 (if you got 1 from device that means 1 byte, multiplying it by 8 gives 8, which is correct number of bits).

Best regards,
Victor

Yes, we will publish packages for Ubuntu 19 in a few days.

Best regards,
Victor

Quote from: tomaskir on September 12, 2019, 12:11:15 PM

Quote from: Victor Kirhenshtein on September 12, 2019, 11:10:31 AM
That's complicated issue. Current implementation is a bit messy with $n variables after matching. Consider the following code:

Code Select Expand


v = "error 43";
if (v ~= "(error|warning) ([0-9]+)")
println("Step 1: $1=".$1." $2=".$2);
if (v ~= "(error .*|info ([0-9]+))")
println("Step 2: $1=".$1." $2=".$2);


In NetXMS 2.2 $2 will be equal "43" on step 2, which is kind of misleading. It was because implementation in 2.2 silently skipping unmatched capture groups. Implementation in 3.0 resets all unused $n variables, which has side effect of clearing $1 if there were no capture groups at all. Looks like it was bad decision to use same names for capture groups and script arguments.

I want to gradually clean up inconsistencies in NXSL, and that could lead to break up of some things. I think that for now I can introduce server configuration variable (off by default) that will prevent resetting of unused capture group variables. Also I will introduce separated naming for script arguments and capture groups so scripts could be migrated over time to non-overlapping variable naming. Also for transformation scripts I think it is worth passing raw value not only as first argument to the script but also as global variable, like $rawValue.

Best regards,
Victor

The problem here is that there are likely thousands of scripts all around the Forums, Wiki and the internet that this change breaks.
Every single one would have to be updated - which is unrealistic.
For new users who find some regex-based scripts on the internet, they will not work, and they don't know why.

Existing implementations (scripts) will start working differently upon upgrade, without any knowledge of the system operators
This will be VERY difficult to track down, as this will not produce script errors, rather things will just work differently.
This means there can be a threshold script which will "pretend" to still work, but in reality will not work.
It puts burden on system operators to review every script they have upon upgrade to check if it still works properly

What I personally would propose:
There are far less scripts using regex capture groups than just regex.
So if a change is needed, only regex capture group should be changed, without affecting regex operations without capture groups (as is the case now).

What about capturing regex returning arrays with captures?

Code Select Expand


matchArrray = "test" ~= "t(e)(s)t";

println(matchArrray [0] . matchArrray [1]);
for (match : matchArrray) {
  print(match);
}


This would clean up the reuse of $1, $2, etc. without breaking ALL regex handling.
The change would only affect a smaller part of community, so less impact.

I've changed regexp expressions to return array with capture groups instead of boolean value. It still sets $n variables for compatibility but does not erase unused variables (so if there is no capture groups in regexp $1 will be left intact). As a side effect it is now possible do directly access capture group from regexp. For example the following code

text = "error 43";
errorCode = (text ~= "error ([0-9]+)")[1];
println(errorCode);

will print 43.

Best regards,
Victor