NetXMS Support Forum

Create a normal server command Object Tools, and as command, use this:
/root/some/script.sh %a %U %(foo) %(bar)

Where foo and bar are from your input fields.
(you still need to configure the input fields in their configuration)

The problem is not in NetXMS, if you only see one interface, it means SNMP communication to the switch is not successful.

You dont need to remove/add the switch, fix snmp communication to the switch, and run a Full Configuration poll on it.

1.2.17 has a few bugs that can cause this.

I really recommend you try 2.0-RC1, it has a lot of fixes and optimizations that will probably fix this for you.

Is the server in the same subnet as your PC or not?
- its possible a transit firewall is allowing ICMP (ping), but not connection to NetXMS.

Does the server have iptables, or any other firewall?
- again, a firewall may be allowing ICMP (ping), but blocking NetXMS.

Hey guys,

In 2.0-RC1, there is a new plugin to monitor LigoWave and Ubiquity devices,
Ligo and UBNT are notoriously known for having very little data in SNMP, hence this collector was written.

This plugin grabs and parses data directly from the json which the web-client uses to show them to you on the device's web-page.

I want to share some results...

LigoWave client showing ccq vs signal:


Ubiquity client AirMax stats:


All data collection for a UBNT AP:


As mentioned, the collector will be included in 2.0-RC1.

For setup instructions, you can go here:
https://wiki.netxms.org/wiki/Ubiquiti_and_Ligowave_wireless_monitoring

Actually, interface state and node's state are 2 different things.

Node is check every "status poll interval" for snmp and icmp reachability.
All interfaces statuses are also checked.

Then the most severe status is then set as the node status.

So if you set interfaces to IGNORE status, node will still be checked and proper alarms will be generated.

If they are not, something else is wrong with your setup, and we need to find out what.

You can place DCIs on the performance tab.
This can be used with template DCIs as well of course.

You can check this out:
https://youtu.be/CH3rFwz7LwM?t=3m29s

You can do all of these in a configuration poll hook.

This is an example to just delete dynamic interfaces, so NetXMS doesnt even know about them:

1) Create a script in script library called "Hook::ConfigurationPoll"
2) Here is the code:

// if this is a MikroTik device
if ($node->snmpOID == ".1.3.6.1.4.1.14988.1")
{
  intArray = GetNodeInterfaces($node);
 
  foreach (int : intArray)
  {
    // if the interface is dynamic
    if ((left(int->name, 1) == "<") && (right(int->name, 1) == ">"))
    {
      // delete the interface
      DeleteObject(int);
    }
  }
}



No idea why your columns disappear, but try resetting the perspective (video 3.1) in the client rather then deleting the whole client.

Let us know if that helped, or if the client delete / re-download is the only way to get them back.

Yes, you can use this:
https://wiki.netxms.org/wiki/MTBF_(Mean_Time_Between_Failures)_and_MTTR_(Mean_Time_To_Repair)_Calculation

Result looks like this:

I did some research and then bothered Victor with questions, and here is a bit more info on this:

Server now uses 2 thread pools; "MAIN" and "POLLERS".
Agent uses 1 thread pool named "DATACOLL".

You can find out by running "grep -r ThreadPoolCreate\(.*\)\)" on the src directory.

You can collect metrics on these using:
For server, Internal Server.ThreadPool.* DCIs are available.
For agent Agent Agent.ThreadPool.* DCIs are available.

You need to pass the thread pool name as {instance} to the DCIs (in the parameter).

Thread pools with automatically shrink and grow. You can monitor this using the "Size" DCIs.
Thread pool load is available using the "Load" DCIs.

Load should never exceed the size of the thread pool, but this should not happen anyway, since the thread pool will grow to accommodate load.

I think you are confusing a few things here.

1) application logs (nxagentd or netxmsd) are NOT syslog
2) You can read up on syslog here http://www.networkmanagementsoftware.com/what-is-syslog

Application logs (nxagentd or netxmsd) are written as configured in the (nxagentd or netxmsd) conf files.
Syslog messages can be sent from any of your devices to NetXMS syslog server.

You can of course direct the application logs to be sent over syslog as well (using the {syslog} setting), but correct syslog deamon configuration on your Linux box is needed.

On Windows, {syslog} means to use the Windows System Log - which is not syslog at all.

As I mentioned, for me it works fine with filtering scripts, but I do not show end-nodes on my map.

Victor will have to shed more light on both the issues

I do not know why script security is being applied here, maybe Victor can tell us.

You are not getting connectors as in the links connecting the nodes on the map?
I get those when using the filtering script.

This is a known issue
https://dev.raden.solutions/issues/829