NetXMS Support Forum

Hi,

Tables are a bit different. Your script is effectively replacing the entire table with one single value.

The following post might help you get this working:
https://www.netxms.org/forum/configuration/transformations-scripts-for-table-dci/

Cheers

You can write a Hook:CreateInterface script to prevent interfaces from being created that you don't care about.
You can also create a Hook:ConfigurationPoll script to automatically check all node interfaces, then set the interface expected state to IGNORE on interfaces you don't want to be alerted on. I wouldn't think you can do that inside the CreateInterface Hook, as the interface doesn't get created until after the script has run, but I could be wrong.

For example the following Hook:ConfigurationPoll will set any network interface on a device detected as a printer to Ignore:
interfaces = GetNodeInterfaces($node);
foreach (interface : interfaces)
{
if ( $node->isPrinter == TRUE ) SetInterfaceExpectedState(interface, "IGNORE");
}

Hope that helps.

That particular MIB appears to have a history of issues:
2013: https://community.cisco.com/t5/unified-computing-system/cisco-unified-computing-tc-mib-won-t-compile/td-p/2096749
2015: https://kb.vmware.com/s/article/2034241

Having said that, I downloaded the MIB from http://www.circitor.fr/Mibs/Mib/C/CISCO-UNIFIED-COMPUTING-TC-MIB.mib and it compiled fine at our end.
But then the memory exhausted part would indicate your system somehow running out of memory while trying to build all your MIBs?
I did a quick check at our end and compiling our pile of MIBs (~ 56MB worth) seems to take up half a gig of RAM while doing so.
I wouldn't think that should be a problem on a server, but then I don't know how many MIBs (and available RAM) you have.

Maybe you can download your MIB collection to Google Drive or similar for Victor to download?

As gdodd said, you will need a tool like https://nxlog.co/products/nxlog-community-edition to forward Windows Event Log messages to a syslog server, as Windows Events and syslog (which is used on pretty much anything but Windows) are completely different formats.

Depending on what you want to do, using Logwatch may be sufficient.
The NetXMS agent monitors the Event Log for specific messages. Once such a message is found, the agent triggers a NetXMS Event on the NetXMS server.
Those events can then be processed via NetXMS Event Processing Policies for alerting or actions.
For our use case, Logwatch is all we need (i.e. we're not using nxlog or any other tool like it).

But if you really want/need to forward every log message from a Windows server to a centralised syslog server for storage/processing, you'll have to use a third party tool like the one mentioned.

I agree that they should be on the download site, but for now you can find them in the archive, e.g. https://netxms.org/download/releases/2.2/2.2.10/

Assuming you want to compile with MQTT support, you'll need to install the matching mosquitto-devel package.
https://breadfit.wordpress.com/2015/06/24/installing-mosquitto-under-centos/ might help (it's a guide on installing Mosquitto on CentOS 7, not specifically mentioning the mosquitto-devel package though).
If you don't need MQTT, simply compiling without it should remove the need for mosquitto-devel.

Yes, the server will run configuration polls on startup and then in regular intervals as per your Server Configuration, so if the configuration polls are the reason for your high CPU usage, you should see this whenever the server tries to run the next batch of configuration polls, too.
You can't turn Configuration Polls off. I guess you could set very high intervals, but really, you want configuration polls to run to pick up changes on your nodes.

Without knowing just how large your installation is, I can't tell what other reasons there might be for your high CPU usage.
I know a test system of mine (which basically collects the same data as the live one) caused my hardware firewall to collapse as it couldn't handle the packets per second, but that's a 250,000 DCI installation and it was a SOHO firewall. My switches and routers had no problems.

I know that some Cisco IOS versions behave badly when you run an snmpwalk against them. There are several tables mentioned in recent IOS bugfixes which can cause devices to stop responding to snmp queries, lead to high cpu usage and SNMP crashing completely - in fact the fixes also happen to be security fixes. So if your network devices with high CPU are Ciscos, my first suggestion would be to install the very latest IOS.

I haven't run a NetXMS server on anything other than Ubuntu, so I really can't tell if this is any better/worse than the other options out there.
One of our reasons for using Ubuntu (other than personal preference) was the availability of NetXMS packages directly from the developers.

I believe Tatjana means updates to be sent from the server to the Management Console (client), i.e. either the server can't send new information to the client fast enough or the client can't accept it fast enough, thus throttling the server. Once that happens, the queue of updates to send just keeps increasing as it cannot catch up. It'll probably do that until the server runs out of resources and trips over - or until the console is closed. The latter explains why your server performance came good whenever you closed the console.

Have you considered using the Web Console for testing (sry, we're using Ubuntu, so can't give any guidance on the CentOS process)?
As that can be installed on the server itself, it would effectively remove the network from the server to console communication.

If you are looking for a 95th percentile for all interfaces you are collecting data for, you can probably use the same type of instance discovery you are using for monitoring those interfaces to create the 95th DCIs. As part of that 95th instance discovery, you can pass parameters to the script. For example if your script is called "myScript" you could call it as "myScript("{instance}")" to pass the instance value through.
That should allow you to locate the DCI to pull the data for the calculation from.

Alternatively, you can configure a custom attribute on each node that lists all interfaces you care about.
You can then read in that custom attribute in your script.

I can't help with thread debugging, but just in regards to the 100% poller usage:
Have you attempted to increase your ThreadPool.Poller.MaxSize in the server configuration? If you are constantly running at 100% usage for that poller, increasing the maximum may help with that. Default value is 250, ours is currently set to ~6000.

I'm acknowledging/resolving/terminating dozens of alarms at each morning and when I've seen this timeout issue in the past, it was usually one of these:
- The Syncer thread is running and taking forever. While this is running, the interface is painful to use. We're using the maximum of 64 threads for this which has reduced these occurrence significantly
- Insufficient RAM on the server. It would still work, but queues would start increasing and everything would slow down.
- I have some large object list expanded, e.g. a template or container with hundreds of nodes in it. This slows the entire interface down. Closing such containers/templates tends to speed things up again. No idea if that's a Java thing or something else.

Not sure if any of the above might apply to you, but maybe it helps.

We're running an installation with ~250k DCIs and our experience with the new version so far:
Total SQL queries handled by the server per minute have doubled (as in "it can do more" as opposed to "more load on the server"), DCI writer queues have halved and are steady, large numbers of unused threads after a spike are closed significantly faster (minutes instead of days) reducing memory pressure.
Overall, this has been a massive boost to performance for our installation.

Thanks

Configure the NetXMS agent on the server as a proxy.
Ensure the firewall is configured to allow SNMP connections from that server agent's IP address.
Place the server and firewall in the same zone in NetXMS.
Configure the server node in NetXMS as the communications proxy for that zone.

That should allow you to poll the firewall via the server.
You can add switches into that zone as well and they'll be polled via the server agent.

Hi,

I'm not a developer and, running the same Java and NetXMS Console version, have not personally encountered the error you're seeing.
More or less common reasons for Java errors (which may or may not apply to you) with the Console would be:
- Running the wrong Console (32bit requires 32bit Java, 64bit requires 64bit Java; that's independent of the OS being 64bit).
- An older version of Java still being installed. Removing any old version can help here.
- A newer version of the Console being copied over an old, existing one. This can leave old files behind which can break things. Removing the Console completely and reinstalling it helps with this.
- Odd leftovers in the %USERPROFILE%\.nxmc\data\.metadata directory. You can delete this and it will be recreated when you restart the Console. Doing so will delete any cached logon information though.

I also just now found your other post where Victor mentioned that this is likely a packaging error which will be fixed in 2.2.8.
Linking it here for reference if other people run into this issue: https://www.netxms.org/forum/installation/netxms-on-mssql-2014/
Based on that, I'd simply wait for 2.2.8.

Cheers

You need to set the Server Configuration variable "EnableZoning" to 1 and restart the NetXMS server.

Cheers