NetXMS Support Forum

Hi Ramesh,

Your connectivity issue to the server was not mentioned previously in this posting, hence I am also not aware of the problem or the fix which Victor is implementing in 2.2.8. Based on the recommendation to upgrade to Java 8, I assume you are facing a Console problem. Unfortunately I am unable to really see anything on your screenshots, as it appears you attached very small thumbnail pictures.

For all I know, 2.2.8 will be released very soon. If Victor fixed the problem you are facing in that version my suggestion would be to wait for the release, rather than to attempt to go back to an older version.

Cheers

Hi Ramesh,

2.2.7 is the current version and I'd recommend going with it, unless you have a very specific reason not to.
For all I know, there are no known issues with LLDP or CDP discovery.

For your Allied Telesis, if it supports LLDP, there should be a menu item for it and global settings where you can enable it.
Otherwise connect via SSH, enter configuration mode ("conf t") and run either "lldp run" or "lldp enable".
Which one to use will depend on the exact switch you're using. If neither works, your switch does not support lldp.
I don't think Allied Telesis support CDP, but I have not really spent much time looking, that's just from the handful of switches I've encountered at customer sites.

With 59 switches, you may want to ensure your discovery radius for the map is set large enough, or it might not show everything that's connected.
When you first create a map, it can also take a while to actually be populated, i.e. if you create a new map and open it, chance is it'll be empty. Give it a couple of minutes to put it all together.

Cheers

ThreadPool.Syncer.MaxSize does indeed not show in the standard configuration. You will also need to restart the server after you change it.
Set it to a value like 4 or 8, then have a look at how it behaves. You can see if the settings are active by checking the "show threads" command.

The Syncer threads are used whenever NetXMS actually writes object changes to the database, the interval between writes is defined in the SyncInterval in the server configuration. Default is 60 seconds (which also means a server crash could lose you up to 60 seconds worth of data/changes). If your objects change a lot or you make changes to templates that affect a lot of nodes, the default single threaded Syncer could be a bottleneck. You can follow the progress of the syncer process if you enter "debug obj.sync 7" and "debug sync 7" in the server console, then check the netxmsd log file. Once the Syncer kicks in, it will log how many changes it needs to write and you can get an idea for how long it takes to do so. It's not a lot of extra messages, but useful information while you're making those changes.

For overall performance, the main threads are probably more relevant.
You can monitor the load of your thread pools by creating DCIs on your NetXMS server itself (using the "Internal" DCIs).
I suggest you monitor some of those to see where exactly you may need to adjust your settings.

It sure can. We're running with 20 cores at present and our average load is around 9, but that's with over 200,000 DCIs.
You can tweak the number of threads being used for different tasks in your server configuration.
It sounds to me like you may not have enough threads configured. Monitor "show threads" in your server console to see if you need to tweak them.
I guess you'll probably want to increase the ThreadPool.Main.MaxSize (default is 256) as well as possibly the ThreadPool.Syncer.MaxSize (default is 1).

Sorry, I don't know the answer to that question, as we're not using the sub-agent.
I do know that different models of APC UPS do not all report everything back (via SNMP that is), but usually the unsupported things are more like Part Numbers or Output Current, not the overall UPS status.

Yep, the script had a typo. Oops. Was only for testing though, so should not affect the actual DCI.

I just set something similar up on a Ubuntu system here and I think the ExternalList needs an update:
ExternalList=Phonalisa.Processes:/bin/bash -c "ps axco command | grep phonalisa- | sort -u"

Using that (i.e. with /bin/bash), it worked for me when I grepped for "imap" processes (returned imap and imap-login). Created two DCIs, one for each and returned the correct values.

Let me know if that works for you.

The script was only to check if the server gets the correct results back from the ExternalList command on the agent.
I'm guessing the ExternalList command is actually incorrect (I haven't used those on Linux yet, only Windows).

The description should include the process names as per your list and you should end up with one DCI per list entry.
Instead it appears the list returns "1" to your Instance Discovery DCI, hence your DCI returns 0, as there is no process called "1".
Not sure what exactly is happening, I'll have to set the whole thing up at my end (not just the script) for comparison/testing.
I'm assuming you're running the latest version of NetXMS?

There should be no need to use the instance discovery filter.
I'm assuming Instance Discovery did run against the Agent?

Setup under General should look something like the attached screenshot.

Please confirm if the list contains the data you expect.
Right-click on your agent, select "Execute server script" and run the following:
processes = AgentReadList($node,"Phonelisa.Processes");
if ( processes == null ) return "The list is empty!";
foreach ( process : processes ) {
  println(process);
}
This should list all the processes it knows about. If it does, then that's not your problem.

But if the above returns "The list is empty!", check that running the command that generates the list produces the expected output.
It worked on my system when I tested it against other processes (I don't have any phonalisa ones), so there is a possibility the command doesn't work as expected on your system.
As the user running the Agent, run the command that generates the list:
ps axco command | grep phonalisa- | sort -u
See if that actually produces the list of process names you expect.

We're using SNMP to monitor UPS' at our end (no matter if connected via network or USB), but I recall using the inbuilt sub-agent once before and I did something similar to what's mentioned in this post:
https://www.netxms.org/forum/configuration/more-detailed-information-to-configure-an-usb-ups/
That is, I didn't use the serial number of the UPS in the configuration file, as there was only one UPS connected.

Other than that, you may need to replace (*) with (0), as that's the number of your UPS in the configuration. Not sure if that's really needed if you only have one UPS.
Or use actual Instance Discovery using the "UPS.DeviceList" list?

Create an ExternalList in your agent configuration:
ExternalList = Phonalisa.Processes:ps axco command | grep phonalisa- | sort -u

That should give you a list called "Phonalisa.Processes" on your agent, which you can then use in your Instance Discovery DCI.

Hi,

On Windows you can use PowerShell to parse the local certificate store to generate a list of certificates. Something like the below should give you a list of certificates in your local computer store and only return the most recent one for certificates with the same subject and issuer, so you don't alert if you leave old certificates on your system beyond expiry.
Get-Childitem -Path Cert:LocalMachine\My -recurse|?{$_.Subject -match "CN=.*\..*"}|Group-Object -Property Subject,Issuer|%{ $_.Group | Sort-Object -Property NotAfter -Descending | Select -First 1}
You can use the output of the above to filter for only the type of certs you care about (e.g. you could remove certificates that were signed by a local CA or similar).
Once you have that list, you can use instance discovery to go through those certificates and pull the expiration date. Just be aware that you'll be getting the expiration date in US format, i.e. MM/DD/YYYY. There's probably a way around that, but my PowerShell is limited .
Using a transform script, you should be able to check on age and alert for example if it's due to expire soon or if it has already expired. Sry, don't have example code for that part.

Or are you after "Connect to website via https and tell me when the certificate expires", in which case you could probably use Nagios' check_http for that (you can configure and call that as an ExternalParameter on your NetXMS server). Again, we're not doing that, so don't have an example config.

Cheers

If you telnet to the public IP on port 4700 from your NetXMS server, does it connect or time out?
If it connects, check your agent configuration file and node setup in NetXMS. The agent might simply not be configured to allow the server to connect.
If it doesn't connect, there's some firewall in the way blocking the connection (could be the Windows firewall).

1 milliwatt = 1000 microwatt, therefore
return 10*log10($1/1000);
will convert microwatt to dbm.

If your device only provides mW values, you will need to use a transform script on your DCI to convert to dBm.
The below should do it:
return 10*log10($1);