News:

We really need your input in this questionnaire

Main Menu

NetXMS 1.2.16 released

Started by Victor Kirhenshtein, August 06, 2014, 07:53:04 PM

Previous topic - Next topic

Victor Kirhenshtein

Hi all!

NetXMS version 1.2.16 is out. It's mostly a bugfix release to fix important issues found in 1.2.15. Full change log is following:

- Fixed database upgrade issues
- Fixed packaging issues
- Fixed bug causing outdated peer information on interface objects
- Fixed bug with upload to agent default path from server file store
- Instance display name for DCIs created via instance discovery
- DCIs created via instance discovery can be combined by instance into one chart on performance tab
- Transformation script terminated by "abort" call will not generate SYS_SCRIPT_ERROR event
- Database manager can detect and fix missing IData and TData tables
- NXSL:
   - String concatenation operation interprets NULL value as empty string instead of throwing runtime error
   - Fixed incorrect processing of ilike, match, and imatch operators
   - Added try / catch operator
- New MIBs added: NETUP-MIB
- Fixed issues: #424, #618, #619, #620

If you are upgrading from version 1.2.14 and below and encounter errors related to missing tdata tables during database upgrade please run command

nxdbmgr check-data-tables

and the run upgrade again.

Best regards,
Victor

Dani@M3T

are these two new features documented somewhere? Sound very interesting.

  • Instance display name for DCIs created via instance discovery
  • DCIs created via instance discovery can be combined by instance into one chart on performance tab

Dani@M3T

any news about these two new features?

Victor Kirhenshtein

It is now possible to set display name for instance which is different from name (it is useful if for example you have to pass actual OID as parameter but want meaningful name in description). Instance name can be inserted into DCI description via {instance-name} macro. To set instance name you should return array of three elements from instance discovery filter: first element must be TRUE, second new instance, and third new instance name. For example, the following script can be used to name interfaces for collecting data from standard interface MIB:


// Get interface name from .1.3.6.1.2.1.2.2.1.2.{instance}
snmp = CreateSNMPTransport($node);
ifName = SNMPGetValue(snmp, ".1.3.6.1.2.1.2.2.1.2." . $1);
return %(true, $1, ifName);


Attached are screenshots with full DCI configuration.

Second is actually very easy - if you attach one instance discovery DCI to another instance discovery DCI, DCIs with actual data created from those will be attached to each other on performance tab as well, using instance as a key to find peers.

Best regards,
Victor

Benjamin Dill

It seems there are still some database issues. I did a fresh install with a new database today (Windows x64, MSSQL) and netxmsd keeps crashing after installation. Then I installed 1.2.14 and did an upgrade to 1.2.16, which worked without any problems.

Dani@M3T

in 'Performance Tab' 'Title' I can't use the macro {instance-name}. Is it not implemented, a bug or my error in reasoning?

Victor Kirhenshtein

Quote from: Dani@M3T on November 26, 2014, 10:42:32 AM
in 'Performance Tab' 'Title' I can't use the macro {instance-name}. Is it not implemented, a bug or my error in reasoning?

You can only use {instance} macro there. But actually you'll got instance name with that macro. Long explanation is following:

{instance} and {instance-name} macros in DCI name and description expanded during instance discovery process. There is "instance" field in each DCI (you can see it's value on "Thresholds" tab) - you can edit it freely for ordinary DCIs but it is populated automatically for DCIs created by instance discovery, and it is set to instance name. Macro {instance} in performance tab configuration expanded when you open performance tab, and value of "instance" attribute of appropriate DCI is used.

Both macros was created when there was only {instance} in instance discovery and it was making sense. Now with introduction of {instance-name} macro it becomes counter-intuitive. I probably can add {instance-name} macro to performance tab just to make it compatible - but still it will not allow to get actual instance value (although I double somebody will need it in graph title).

Best regards,
Victor

Dani@M3T

Hi Victor

Thanks for the detailed explanation. So I can use {instance} in the performance tab title for the moment to get the instance name. But for me the current situation is inconsistent. But the question is, what to do for the future. Is it a good descicion to use {instance-name} for the DCI instance field? For me this is a little bit inconsistent. But then the problem would be how you get the {instance-name} in the performance tab. And if you would introduce a DCI-field 'instance-name'?

I got another problem in this context with attaching a performance tab to another one in templates with instance discovery:

DCI1 in Template: Description: "Network Interface {instance-name} in"
DCI2 in Template: Description: "Network Interface {instance-name} out"

Then I attached the performance tab of DCI2 to to one of DCI1 in the template. But on the target node I only see the performance graph of DCI1. Is the {instance-name} in the template DCI description maybe the problem?

Dani@M3T


Victor Kirhenshtein

Hi,

I just fixed that. Fix will be included in 2.0-M1 release.

Best regards,
Victor

Dani@M3T


Dani@M3T

it works in 2.0-M1 release, thanks!