NetXMS Support Forum

How are you collecting the timestamp and how are you transforming it?
It sounds like your transformation happends in UTC, whereas your timezone is +2.

You can see how NXSL time-related functions work in this example script:

// current time in Unix time
timeVar = time();

// lets convert to time object in UTC timezone
timeGM = gmtime(timeVar);

// lets convert to time object in our local timezone
timeLocal = localtime(timeVar);

// lets print all of them
// remember this is in UTC timezone
println(timeGM->year . "-" . 1 + timeGM->mon . "-" . timeGM->mday . " " . timeGM->hour . ":" . timeGM->min);
// this one will be in our local time, because we are using localtime() function
println(timeLocal->year . "-" . 1 + timeLocal->mon . "-" . timeLocal->mday . " " . timeLocal->hour . ":" . timeLocal->min);
// this one should be the same, since strftime() function works in localtime
println(strftime("%Y-%m-%d %H:%M - timezone %Z - offset from UTC - %z", timeVar));


You dont write script to work with SNMP Traps.

Go to Configuration > SNMP Trap Configuration.
Here you can create trap mappings and specify OIDs of parameters that the trap contains.

Events you can configure in Configuration > Event Configuraration.
Here you just create an event and how many parameters it has (which it will receive when the trap generates the event).

In EPP, you can then do things based on that event (create Alarm, send email, etc.).
This is in Configuration > Event Processing Policy. You can find many examples already there and base your EPPs on those.

If you have any specific questions, feel free to ask

What is the POLLERS thread pool size?
General rule is load average should never be higher than current pool size.

Usage of the thread pool should also never reach 100 (its percentage), if it does consider increasing PollerThreadPoolMaxSize server config variable.

1) Enable PortCheck subagent
Add this line to the main section of the agent config file on the server
SubAgent = portcheck.nsm
Restart the agent so it loads the new config and the SubAgent.

2) Create a DCI on the monitored server node.
Origin "NetXMS Agent"
Click "Select" next to "Parameter"
Find "ServiceCheck.Custom" and use it.
Modify the "Parameter" like this (substitute node IP for 1.2.3.4):

ServiceCheck.Custom("1.2.3.4", "4700", "1000")

Set "Polling mode" to custom and to 1 second.
Set "Source node" to your NetXMS server.

3) Set threshold to create alarms when NetXMS Agent connection is unavailable
Under the DCI, go to "Thresholds" section
"Add" and just change "Operation" to "!= : not equal to" and keep "Value" at 0

Can you please confirm if you see the static entries for the Cisco switch node in its Object tools > Switch forwarding database (FDB)?

I have also created a new ticket:
https://dev.raden.solutions/issues/1129

Rather than just making the alarms go away, I would suggest investigating the root issue, if NetXMS agent really is unreachable or not during those alarms.

You can start with some simple debugging like this:
Setup monitoring of TCP port 4700 from the NetXMS server to the node (with for example 10 sec poll time), and see if the server does or doesnt actually have connectivity issues to the NetXMS agent on that node.

This was fixed in one of the 2.0 RC releases.

Are you running 2.0.1 and is it still not working?

I currently have one deploy at 1k nodes and 2 other at 300 nodes.

You will find people here on the forum with 3k+ node deploys.

I really suggest you contact Raden and get official support for the issue.

They will be able to solve it fast.

You can write them in C++ only currently, but there is already an open feature request to be able to write them in NXSL.

You can keep track of it here:
https://dev.raden.solutions/issues/498

Yes, node will be considered up (since it does reply to ICMP after all), and "SNMP Agent is not responding" alarm will be generated.

For example, if a http server is running one the node, and node replies to ICMP as well as HTTP (assuming you have http service monitoring DCIs), it would not be correct to mark the node as down. SNMP service might have crashed, but rest of the services on the node might still be up.

So basically, if node responds to ICMP, its considered UP (but SNMP or nxagent might be down, which will generate corresponding events).
If node does not respond to ICMP, but does to SNMP or nxagent, it is considered UP as well.

If node does not respond to any (ICMP or SNMP or nxagent - assuming all of them are turned on to be used in the Status polling), then its considered DOWN.
(as mentioned previously, you can turn off ICMP or SNMP or nxagent checks during status poll for a node)

Node status is periodically collected (determined by StatusPollingInterval of Server Configuration).
That status is held internally for each node as one of its parameters.

1) Status DCI was just the node's status collected into a DCI.
You can still create this DCI yourself if you want, or just get current status with a script (right click on node -> "Execute server script").
return $node->status;

2) Status poll checks ICMP, SNMP and nxagent.
You can configure which is used on a per-node basis (right click on node -> Properties -> Polling).

3) If a device uses multiple methods, each method (icmp, snmp, nxagent) is checked.
If SNMP or nxagent do not respond during status poll, proper events (and then alarms according to EPP) are generated.

If you run a manual Status poll on a node, you can see all these checks and their logs in the log of the Status poll.

Update for release of NetXMS 2.0!

v2016010701:
  Added new functions from 2.0 release to syntax highlight and calltips
  Fixed cosmetic errors in Calltips
  Fixed multi-line comments not being styled
  Fixed escaped quote breaking styling in strings
  Files moved to GitHub

All the files are now located on GitHub at:
https://github.com/tomaskir/netxms-notepad_pp.git

What version are you running and what OS?

That will be a memory leak in NetXMS.

2.0 will be released soon, there were a lot of fixes.
I would suggest waiting a little for 2.0, and after the upgrade, please let us know if the memory leak persists