NetXMS Support Forum

https://wiki.netxms.org/wiki/NXSL:GetDCIValue might work.
As you are in the transform stage, the value that you just collected can't be returned as a result yet, which means it should return the previous one?

Hi,

Based on what I can see at http://www.oidview.com/mibs/3417/SENSOR-MIB.html, the value you are trying to poll is part of a table.
That means you should probably create a single template using Instance Discovery using .1.3.6.1.4.1.3417.2.1.1.1.1.1.1 as Base SNMP OID, instead of creating two different templates. You could probably also poll 1.3.6.1.4.1.3417.2.1.1.1.1.1.9 as part of your Instance Discovery script to return the name of the sensor for the DCI.

The filter script would look similar to this:
transport = CreateSNMPTransport($node);
if (transport == null) return null;
sensorName = SNMPGetValue(transport, ".1.3.6.1.4.1.3417.2.1.1.1.1.1.9." . $1);
if (sensorName == null) return false;
return %(true,$1,sensorName);
I have no idea if the sensor name will always exist on this device or not. The code above will not create a DCI if a name does not exist. In fact, it will remove it if it can't find a name.

You can then reference the sensor name in your DCI description as {instance-name} and the instance itself in the DCI parameter as {instance}.
The parameter should therefore look like this:
.1.3.6.1.4.1.3417.2.1.1.1.1.1.5.{instance}
The description could be this:
Bluecoat Temperature Sensor ({instance-name})

Cheers

I haven't actually tried this with interfaces (done something similar, but not quite the same with nodes), but the following should work:

• add the email address you want as a custom attribute to the interface
• Create a new action using macro %M (the "CUSTOM_MESSAGE" or a filter script, you will set this later) as your email recipient in your action
• Create another event processing policy for the event you want to alert on, above the original. Configure it to use the action above.
• reference the custom attribute you create earlier in the event processing policies filter script and return its value as CUSTOM_MESSAGE. If the custom attribute does not exist, return false in the filter script. Event processing will continue on "normal" interfaces and hit the next rule, alerting as normal, while interfaces with the custom attribute will trigger this policy and use the custom email address for alerting

Some very basic links regarding event processing and scripting:

• https://www.netxms.org/documentation/adminguide/event-processing.html
• https://www.netxms.org/documentation/adminguide/scripting.html#scripting

There are several event processing policies related to interface state changes, which you can either change or disable and configure your own.

You could for example add a filtering script that checks if a node is reachable via SNMP prior to triggering an alert. That way, if the node was down, you would receive the node down, but not the interface down alerts. If the node was up, the interface down alerts would still come through:
snmpTransport = CreateSNMPTransport($node);
if ( snmpTransport == null ) return false;
return true;
Technically NetXMS should be detecting that the node is down and thus not alert on the interfaces going down as well. I am not sure if that works or doesn't work - as I said, we are not alerting on that.

That also still doesn't help you if you have a whole bunch of interfaces go down while the node is still up.
Not sure how NetXMS is supposed to group those into a single email alert, as the events come in individually.
To group them, NetXMS would have to delay sending the email for the first event while waiting to see if any additional events come in.
Maybe the AlarmSummaryEmailSchedule, AlarmSummaryEmailRecipients and EnableAlarmSummaryEmails Server Configuration options can help you with that. I am not sure how much flexibility you require in regards to email recipients for different devices. We have never used these summaries, so I actually do not know how they look like at all.

You can create a script, which can then be called via Object Tools.
For example the following works to reboot Cisco routers:
snmpTransport = CreateSNMPTransport($node);
if ( snmpTransport == null ) return "Unable to connect";
returnValue = SNMPSet(snmpTransport,"1.3.6.1.4.1.9.2.9.9.0","2","INTEGER");
if ( returnValue == null ) return "No response. Something went wrong.";
if ( returnValue == 0 ) return "Unable to initiate reload. No SNMP Write Access?";
if ( returnValue == 1 ) return "Reload triggered.";

In the Object Tools configuration, you create a new Tool of type Server Script and call the script you saved by name. So if the above was called "ReloadCisco" in your Script Library, then that's what you'd call.
You will probably also want to filter the Object Tool to ensure it doesn't show against systems that can't handle it.
And of course you have to have SNMP Set/Writes enabled on the device and have that community configured on the node in NetXMS.

You can configure the poll count per interface (open the properties of the interface, select Polling and set the required poll count).
You can also globally configure this by changing the PollCountForStatusChange server configuration setting. Default is 1.

I guess you could also look at Filtering Scripts in Event Processing Policies to not send/trigger an alert for interface up/down if the node is unreachable (e.g. try to connect via SNMP inside the script or check some other node conditions).

In our case, we require three polls for a status change, but we also check the status more often than once a minute (which is the default).
We also are not actually alerting on interface up/down. The node will still show as critical in the list (i.e. red cross) if an interface is in an unexpected state, but there are no emails. That is sufficient for our setup, but may be unacceptable in yours.

The following should actually work:
if ($1->name ilike "*fa*") { return false;}
return true;
Note that that your code was comparing to "*fa.*"

You could also use:
if ($1->name imatch "fa") { return false;}
return true;

Hi,

You can get the values of the varbinds, but I don't think you can get the varbinds themselves.
I don't think you can query the SNMP Trap Log via NXSL either, but I guess you could trigger an action that calls a script on the server which pulls the information from the database or via nxshell (i.e. trigger an action on the event via event processing policies, with the action pulling the information out of the logs).

Alternatively you could:
- setup DCIs to actively monitor the status of your BGP peers via BGP SNMP table, but that won't be as "instant" as an SNMP trap.
- use Syslog, where you can grab the relevant information from the message

Some example syslog from a Cisco:
%BGP-3-NOTIFICATION: sent to neighbor 192.168.255.5 4/0 (hold time expired) 0 bytes
%BGP-5-NBR_RESET: Neighbor 192.168.255.5 reset (BGP Notification sent)
%BGP-5-ADJCHANGE: neighbor 192.168.255.5 Down BGP Notification sent
%BGP-5-ADJCHANGE: neighbor 192.168.255.5 Up

Someone else may have an easier solution?

Cheers

Hi,

I believe that can happen if a device is scheduled for removal, but hasn't actually been removed from the database yet.
In memory, it will be gone (hence you can't see it in the Console), but it is still in the database (causing conflicts when you try to re-add the node).
The syncer thread which runs every minute by default should write updates to the database, but I guess it could be running into problems.

Try setting debug for obj.sync and sync to 7 and watch the NetXMS server logs after you delete the object.
To enable debug open the NetXMS Server Console and enter "debug obj.sync 7" and "debug sync 7".
An example of a deletion gone wrong from our logs:
Object 120.150.216.0/24 [205198] marked for deletion
Unable to delete object with id 205198 because it is being referenced 8 time(s)
In our case the above was removed after about an hour (we run the syncer every 5 minutes), presumably because the references were eventually removed.

Cheers

Hi,

What happens if you run a full configuration poll on the node that is no longer being polled?
That's under the assumption that you know/are sure that the node's agent/SNMP are working perfectly fine.

I've seen situations where the server would stop polling SNMP or the agent itself, but a full configuration poll would just fix it (a normal poll would not work because the node was unreachable - and status polls would never return an ok status). I never found an actual underlying cause or solution for this behaviour, nor could I reliably reproduce it.

Cheers

I recall seeing this issue in the past, when I removed a node from a zone, then tried to move another node into the same zone and both nodes had the same IP.
The system had not actually updated the database yet and kept telling me the IP already exists. Could take quite a while, but this usually resolved itself (or I grew impatient, restarted the service and tried again).

Haven't seen this in a while though. We're running 2.2.4. If you are running an older version, there may have been changes/fixes regarding this behaviour?

If you have an unreferenced object, you probably need to shutdown the NetXMS service and run nxdbmgr check to clean that up. Not sure if you can safely delete the object straight from the database without leaving leftovers somewhere.

I don't think the system "queues" alerts during maintenance and upon leaving maintenance checks which ones are still valid.

For all I recall maintenance mode simply stops alerts from going out.
Result in your case: NetXMS will detect the change from Up to Down. As the devices are in maintenance mode at the time, the alert won't be sent.
As the status then doesn't change (i.e. it stays down) there is no alert. I think the repeat interval will eventually trigger a new alert, but that could be a while.

Hi,

That is not related to importing a MIB file, but an issue that was fixed in version 2.2.4 (MIB Walk from DCI missing Column).
It should work once you upgrade to the latest version.

Cheers

Hi,

Probably related to this: https://www.netxms.org/forum/configuration/windows-updates/

Short version:
Microsoft removed the relevant registry values from Windows 10 and 2016.
You can work around it via scripting and ExternalParameters.

Cheers

Hi,

On Windows, I am at times seeing an issue where the NetXMS service will not restart (either after an upgrade or a manual restart attempt to load a new configuration).
Checking the logs, I this is generally due to a the NetXMS agent port still being in use by PowerShell (which we use extensively for Parameters, Actions and ParametersProviders). The actual NetXMS agent service is stopped, the process is not running, but a PowerShell process which was started by NetXMS is still active and for some reason managed to hold the agent's network port open. The system does not recover from this by itself, we have to go in manually and kill powershell.exe, after which the NetXMS service will start again.
Not sure if this is an issue where the NetXMS agent either does not clean up all external commands (properly) prior to shutdown or if at some point it just loses track of one of those commands, which is then never killed and just keeps sitting there.

We've had this issue for a while and this is appears to impact maybe a handful of systems a week (I have two systems which seem to have this problem pretty much every week, other systems appear to be more random). Considering we have 2000+ agents, it's certainly not a huge issue, but it is quite a nuisance to pick up on this  (with some systems which we do not expect to be on all the time, this problem may be ongoing and we wouldn't even notice) and resolve it.

I am pretty sure we have this problem prior to starting to implement ParametersProviders and we are not regularly running actions against the two recurring systems, so I have to assume it's just an external parameter problem.

Has anyone else encountered a similar problem?

Cheers