NetXMS Support Forum

Hi,

Since installing the NetXMS 2.0.4 Management Console I a m having issues with graphs with "Invert values".
If the values are of type "Area", they work fine. If they are of type "Line", the scale will change, but the line will not be inverted on the graph.s
So if the y-axis was going from 0 to 20M, it will now show -20M to 20M, but the line itself will not be inverted. As soon as I switch to "Area" it works fine.
Not sure if this is related to the actual values in the legend now not being inverted either. I recall in 2.0.3 when I inverted a value, it would show as negative in the extended legend, too. It no longer does that in 2.0.4 (which is good ).

Note: I have not upgraded the server to 2.0.4 yet (waiting for repository update for Ubuntu), but this looks like a Console, not a Server issue.

Has anyone else noticed this behaviour?

Thanks for the new release, can't wait to give it a spin.
Could you please update the Ubuntu repository with 2.0.4.

Hi,

I'm wondering if it's possible to build my own network driver or if there are any plans to put in some kind of customisable driver which allows adding OIDs for VLANs, hardware, port configuration, etc. per node? The latter might be more scalable than building custom drivers per device type?

Alternatively, what information would be required to build a driver for a (Brocade) switch that doesn't pick up VLANs, LAGs, components or ports with the current ones?

Cheers

Looks like that was it. No more segfaults.
I have attached the template that is causing the problem.

After some digging in the database (prior to removing the template from all relevant devices) I found that the devices (old Intel Modular servers) appear to send "SCM Comm Error" as response to random values at times. The template includes a number of Integer and Int64 fields, including in SNMP tables. Not sure if that's what is causing the problem, i.e. NetXMS receiving "SCM Comm Error", trying to put that into an Int64 field?

I may have found the culprit. There have been two segfaults right after the same type of DCI alarm was triggered. And a third one just now, "live" while I was connected. An alert popped up relating to that type of DCI and NetXMS died together with displaying the message. However, there were several segfaults without a directly related log message. So to confirm, I've made some config changes and am now monitoring to see if the segfaults actually stop.

Will update the post once I have some more data (i.e. no segfault in the next 24 hours would be a good sign).

We're not using the NXSL function for the ExpectedState (yet), but we certainly have some SNMP traps coming in.
Maybe some device we're monitoring or added recently is having issues and just happens to be sending one of those "bad" traps.
Guess I'll wait for 2.0.4 and see what happens.

NetXMS Version 2.0.3
Running on Ubuntu 14.04.4 LTS, using packages from "deb http://packages.netxms.org/ubuntu trusty main".

nxdbmgr comes back clean. But I guess that doesn't mean it couldn't be some database corruption bringing NetXMS to fall.

Hi,

For the last couple of days the netxmsd process on our server has been segfaulting randomly. Randomly in that debug logs ( at level 8 ) do not hint at the same thing being done prior to the crash. However it does usually take a couple of hours before the process crashes.

Not sure how to troubleshooting this?
I've been reading up on gdb and am following some suggestions from this post: http://stackoverflow.com/questions/16169022/debugging-a-running-daemon-using-gdb
Not sure if that is going to produce any useful output at all.

Anything else I can do to troubleshoot this?

Thanks

I think this is likely directly related to my post here: https://www.netxms.org/forum/configuration/instance-discovery-performance-tab-and-attached-dcis/

If you have two DCIs created from instance discovery, make sure that the first one created by instance discovery is the "primary", i.e. not attached to anything else.
The other DCI which is created afterwards can then attach to said "primary" and it should all work.
The order of your DCIs for this is important.

Cheers

I keep running into a problem when using templates that hold instance discovery DCIs which are to be attached to another DCI for display on the Performance tab.
In the template itself everything looks fine.
But as soon as the template is applied, the Performance tab will only show the "primary" DCI, not the attached one(s).
When I check the actual DCIs that are not showing, I receive a pop-up as I open them, stating
'Resolve DCI name' has encountered a problem.
Cannot resolve DCI name: Invalid DCI ID
The actual instance DCI itself already produces the above error message, hence all instances do, too.

To make matters more confusing, this doesn't always happen.
I have some instance discovery DCIs using the NetXMS agent which work just fine.
Now I just added some for network interfaces via SNMP and none of them work properly.


And just as I typed all of that, I think I found the issue (still leaving all the above text in case it helps someone in the future).
It's the order of the DCIs for instance discovery.
The first DCI in the list (by DCI ID, not name) must be the "primary", otherwise the "discovered" primary DCI doesn't exist by the time the second/third/etc. are trying to attach to them, hence the process fails. Makes sense, but feels counter-intuitive having to watch the order in which DCIs are entered when setting them up.

No idea if that's something that could be worked around in the code to make it less reliant on the order in which DCIs are entered? For example don't "attach" the DCIs until Instance Discovery has been completed?

Hi Victor,

The devices are WatchGuard firewalls (XTM870, XTM330 and M200) and monitoring is done via SNMP.
I've attached the snmpwalk output.

Cheers

Looks like the package didn't come with the SNMP proxy (or I've broken something else), so I guess I'm back to my issue with not being able to get the agent to run after compiling from source.

If the issue is the increase in disk space usage and MySQL not freeing up space, I'm guessing this is InnoDB.
Depending on your settings, you may be able to reclaim the space. See the following link for some background and details:
https://www.percona.com/blog/2013/09/25/how-to-reclaim-space-in-innodb-when-innodb_file_per_table-is-on/

In regards to how quickly the database grows, that would really depend on how much you are monitoring, how often you are checking and indeed your retention.

For comparison purposes:
With our current setup, we have around 15k DCIs (some monitored per minute, some per hour) and 80 GB of disk space in use. And retention for most items currently goes back maybe 2 months. So if you monitor a lot and want the retention, I recommend more disk space.

That worked fine, thanks for the packages.
Now I just don't know what I did wrong with compiling from source?

Hi,

I'm trying to compile the NetXMS agent from source on a Raspberry Pi 3 (wouldn't mind just using a package instead ).
The following command line runs through ok:
sudo ./configure --with-agent --with-snmp --with-client --with-client-proxy
After that I run
make
make install
So far so good.

But when I want to actually run the agent (be it via nxagentd or sudo nxagentd, makes no difference), I receive this:
nxagentd: error while loading shared libraries: libappagent.so.2: cannot open shared object file: No such file or directory

So I ran ls -l /usr/local/lib/libappagent.* and got this:
-rwxr-xr-x 1 root staff  1144 May  3 23:55 libappagent.la
lrwxrwxrwx 1 root staff    20 May  3 23:55 libappagent.so -> libappagent.so.2.0.0
lrwxrwxrwx 1 root staff    20 May  3 23:55 libappagent.so.2 -> libappagent.so.2.0.0
-rwxr-xr-x 1 root staff 45432 May  3 23:55 libappagent.so.2.0.0

To me that looks ok. Not sure why nxagentd has a problem with this?
Any suggestions?