NetXMS Support Forum

We decide that we do official packaging when planned features and fixes are ready. As third number in version is generated automatically from git commits it cannot be predicted. i think that lightweight tags is a way to go, we will just put lightweight tag whenever we do deb publishing. We can agree on certain format for those tags so you will be able to distinguish between deb releases and other tags.

Best regards,
Victor

If acknowledged alarms will be removed from active alarm list how they would be different from terminated? Idea is that alarm browser shows you all problems that are not solved yet. If your business process requires only two states, you can simply terminate alarms instead of acknowledging them.

Best regards,
Victor

Hi,

please use this link for upload: https://cloud.radensolutions.com/s/88sd5KwD2SaAewE

Best regards,
Victor

Hello,

I think we can use lightweight tags for marking release versions. Also, you can use this simple script to switch to specific X.Y.Z version within source tree: https://github.com/netxms/netxms/blob/master/tools/switch_to_version.sh

Best regards,
Victor

It should be on NetXMS server.

Best regards,
Victor

Then it's likely bug in agent. Try to read multiple values directly from agent with nxget:

nxget -i 1 node_ip 'Net.Interface.BytesIn64(1)'
nxget -i 1 node_ip 'Net.Interface.BytesIn(1)'

and check if output looks valid or not (replace node_ip with actual IP address).

Best regards,
Victor

Hi,

you can access all alarms via "Entire Network" or "Infrastructure Services" objects. FOr example, the following script will print all alarm messages:

for(a : FindObject(1)->alarms)
{
println a->message;
}


Best regards,
Victor

It is delta value (average per second). As raw value does not change delta is always 0 - perhaps there is no traffic on interface?

Best regards,
Victor

Hi,

looks like those tdata tables are from very old version, where we did use foreighn keys and related tables. It is safe to use DROP .. CASCADE on tdata tables. You can do that manually for each listed table, and next patch release will use DROP CASCADE for tdata.

Best regards,
Victor

Quote from: wuwei on May 07, 2021, 01:25:44 PM
Hi Victor,
it seems that binary packages for debian/ubtuntu repos at http://packages.netxms.org for this patch release have not been generated.
Is it correct? Are these repositories still maintained?

Thank you.

Hi,

new version should be available in repository now.

Best regards,
Victor

Table functionality predates instance discovery. It was first attempt at handling multi-instance data, and it turns out to be quite complex in configuration and storage. Then instance discovery was added, and in my opinion it is much better approach for collecting multi-instance data, with tables have only limited use. Tables could be used when data really needs to be processed as a table - when you need to combine data from multiple columns and multiple rows (instances) for example. They also could be easier way to present multi-instance data on dashboards.

Best regards,
Victor

Do you really need a table or you can replace it with instance discovery? If yes then you can just set usual threshold on DCIs.

Best regards,
Victor

You have to create it by running reconf script if you clone GIT repository. Or just use source package that I've provided in the post.

Best regards,
Victor

Just fixed it, commit 368c35ad0d in branch stable-3.8.

Best regards,
Victor

P.S. Download link to new source package for convenience: https://cloud.radensolutions.com/s/JCLQKsm3c8YSYSJ

If you have it a s a node in NetXMS, then server will generate usual SYS_NODE_UP event. All you have to do is to create rule which somehow will filter SYS_NODE_UP eents only for such nodes. It could be filter script that check container membership or certain custom attribute.

Best regards,
Victor