NetXMS Support Forum

I don't think there's a way to do this in the GUI.

I had a quick look to see if it would be enough to change the "map_type" in the "network_maps" table in the database to "0" for the map in question (based on our table it appears that 0 = Custom, 1 = Layer 2, 2 = Layer 3) and to remove all seed nodes from it - the result was that the map I was testing with became extremely slow to work with (and ended up with over 3000 links, rather than the 30 it had before - most likely the reason for the speed issue). Changing flags to match another custom map did not help and I ended up wiping the map.
There may of course be a safe way to do this if steps are taken in the right order, but I am pretty sure it's not exactly "supported" and may trigger all kinds of unwanted side effects.

Hi Adrian,

I set something similar up a while ago: a DCI assigned via template using a script to fetch the custom attribute I needed.

And I think that's part of your issue: The script is not interpreted "live" every time the DCI is called - it is only interpreted when it is applied via a template.
Once applied, the actual DCI parameter on your node will then no longer reference the script, but will contain the value that the custom attribute had at the time the template was assigned. Changing the custom attribute later on, no longer changes the DCI parameter. In other words, the potential flexibility of changing a DCI parameter "on the fly" isn't really there.

I have not tested if this is still true with the latest version, but that's how it worked back when I had a go at it. If that's still the case, it's probably worth checking if there is an open feature request.

Cheers

I agree on the DCI Image part. I've had to create a number of them manually as well, then re-create the rules. It can be quite tedious.

As you already created manual, separate links between interfaces which you manually added to the map together with manual DCI images, you are probably at a stage where creating a custom map manually may make more sense.
In that scenario, no automated links between devices will be created - you have to add every item yourself.

You could use ServiceResponseTime.HTTP for basic response time checks, something like "ServiceResponseTime.HTTP(<SERVERIP>,80,"<FQDN>:/<PATH>"). See https://wiki.netxms.org/wiki/Subagent:PortCheck for some documentation. You will need to have an agent that has that subagent loaded and you will need to select that as the source node for the check.

But it sounds more like you are looking for website load time monitoring, which is a bit different.
For that, you probably want to use something like http://www.seleniumhq.org/ to build a script to go through the website, then utilise https://exchange.nagios.org/directory/Plugins/Websites,-Forms-and-Transactions/check_selenium/details and call that via ExternalParameters in NetXMS.

You can add a DCI Image to your map, e.g. next to your interface.
That image can then be based on the status of your DCI. You could show a green icon as default value and a red one if the status if the status is something else (the rules here are quite flexible). That is not quite the same as assigning a status to the interface itself, but it might be sufficient for what you are trying to achieve?

Hi,

Regarding Q2:
You can use an SNMP Table DCI or Instance Discovery.
For an SNMP table, create a "table" DCI (as opposed to a new "parameter"), select SNMP as Origin and enter the table's index OID as Parameter.
In your case, I think that's .1.3.6.1.2.1.17.2.15.1.1.
Then add whatever columns you want to collect from that table under the Columns section, e.g. .1.3.6.1.2.1.17.2.15.1.3 for State. If required, go through the MIB Explorer tool to work out what's available.
I haven't tried to reference a table DCI in another script, so I can't tell how well that will work. I know alerting can be an issue and graphs are not as easily accessible.
You may also want to filter the number of interfaces down to only those that have STP enabled.
I haven't worked with this particular table and am not sure what values to expect.

If you intend to use the DCIs for alerting or to reference in other scripts, you may be better off using Instance Discovery.
Just create a new DCI, use SNMP as Origin, enter the OID you want to query, e.g. .1.3.6.1.2.1.17.2.15.1.3.{instance} for State, as Parameter and under Instance Discovery select SNMP Walk - OIDs with Base SNMP OID set to .1.3.6.1.2.1.17.2.15.1.1.
Again, you may want to filter for interfaces with STP disable or admin status down or only interfaces with an expected state of up.
You may also want to add some logic to that filtering script to grab the actual interface name and return that for the {instance-name} for your DCI Description. I am pretty sure there are several posts on the forum with examples for that.

Q1 is something I have encountered myself and do not have a solution for.

For Q4, I haven't done this and I am not sure if it would work with Table or Instance Discovery DCIs. You can manually change the properties of a link to set the colour based on an object status. That object can't be a DCI though. However, it could be a Condition, so you could setup a Condition to have a status based on your DCI status. But as I said, I don't think that'll work for a table. And for an Instance Discovery, the link between DCI and Condition will be gone if that instance is ever "rediscovered", which at present is not too uncommon. There's an open feature request to keep instances "alive" for a while, even after they can no longer be found (e.g. at present a temporary glitch or connectivity issue could wipe all your instances and historic data).

Cheers

Hi,

As I said, the agent initiates the tunnel, but the server does the polling.
How often the server queries is up to you and your server (status/configuration/instance discovery polls) and DCI configuration.
If you decide to poll every item every second, your bandwidth (and server) requirements will indeed be very high.

The negligible point was in comparison to the bandwidth that would already be required for data collection (without the tunnel).

I am not quite sure in regards to your "constant 32 Megabyte draw" calculation, but our figures may be of help to you:
We have around 2500 nodes in our system (probably a quarter of which are agents, 100 of which are configured as agent tunnels; the rest is network equipment; once agent tunnels are stable the number of overall nodes will double) with over 60,000 DCIs. We do not poll all DCIs every second. Based on the expected change rate, we poll some things daily (e.g. serial numbers), others every hour, every five minutes or every minute. There are very few items we check every second (maybe one or two dozen) - we usually reserve this for live troubleshooting purposes.
The network gear sends through syslog data and SNMP traps (this is indeed pushed as it hits the agent, as opposed to DCI polls).
With the above setup we're at roughly 5 Megabit per second.

Cheers

Are you asking about the push DCIs or the standard agents that establish active tunnels to the server?

The latter establishes an SSL tunnel on startup and from what I can tell whenever the tunnel breaks down. The agent does not push anything in this setup, the server initiates all queries, except it sends the requests via the established tunnel rather than directly to the agent's connection hostname/IP. So from a bandwidth perspective, it should be roughly the same as before + the SSL tunnel overhead, which I'd personally consider negligible. If the tunnel overhead brings your connection to its knees, it probably should have been upgraded a while ago.

I can't comment on the load too much, as we are currently only running around 100 active agent tunnels and the overall load doesn't really seem to have increased.

However, the load data is not very accurate, as our server has been crashing a lot since we upgraded to 2.1-RC1 and started using active agent tunnels. Apparently there was an issue here, which has been fixed in the development branch. With the full 2.1 release expected soon, I'd wait with setting up active agent tunnels until then.

Well, ignore me. Looks like I hit a bit of caching that caused me grief here.
It's still the same principle as with Agent Commands.
<script> %(inputfield1) %(inputfield2) ...
and reference as $1, $2, etc. inside the script.

All works.

Hi,

I was wondering if it's possible to pass parameters to a "Server Script" called via Object Tools (and reference them inside the actual script).
I know I can pass an input field as %(inputfield), but while I can make this work with an Agent Command, I seem to have trouble with Server Script types. Has anyone done this and give me some pointers?

Thanks

I'm running on Ubuntu, so can't help with CentOS specifics, but to check which server version you are running, simply run "netxmsd -v". Compare that with the version of the Management Console you are running.

Depending on how many nodes/items you have in your server, it can also take several minutes between restarting the service and you being able to log in. The error in between would be a Connection Refused, not an incompatible version error.

Check the netxmsd log file and look for the "NetXMS Server started" line, which indicates that the system is ready.

If you locked yourself out with your password change, running "nxdbmgr reset-system-account" should reset the password to default.

That error message usually comes up when your Console or Web UI is running a different version than that of your NetXMS server (and is generally not related to your password at all). Make sure that your NetXMS server version matches the Console. That includes minor version changes, e.g. 2.0.7 is not compatible with 2.0.8.

Cheers

Hi,

Graphs at our end are working ok with RC1.

You probably checked that already, but just to confirm: You do have data for the selected time range?
There are no time problems on your server causing it to collect data with some future/past date or similar, i.e. the Last Values timestamps are current?

Cheers

Hi,

I noticed that the Interfaces tab seems to only accept 1-to-1 links.
When two switches are connected via LAG for example, only one of the interfaces one each switch will show as being connected to the other end. Same with servers connected via LAG.

We also encountered a network the other day, which did have a network loop in it. STP had blocked one of the interfaces so there was no obvious impact.
In this case, NetXMS was showing interface A on switch A to be connected to interface X on switch B - and the interface was down.
Switch A's interface B was also connected to switch B on interface Y - and this interface was up. However, NetXMS did not show peer nodes on those interfaces.
Interface A's peer node had been detected via STP, while Interface B was showing in LLDP.

I am not sure if NetXMS' design allows for handling of n-to-n relations when it comes to peer nodes?

Cheers

Hi Victor,

Had not ever had to do this before, so it was a bit of a learning experience.
Just putting the notes down here in case it ever comes in handy for someone else (or as a reminder for myself if I need this again)

Edited /etc/security/limits.conf and added lines to allow "core" dumps up to 10GB (soft and hard limits). The default is "0", i.e. disabled.
Edited /etc/sysctl.conf and set the kernel.core_pattern to /var/tmp/core-%e-%t.

Worked fine and sent links to core dumps in a private message.

Cheers