NetXMS Support Forum

I believe you need to change the URL in your sources file to http://packages.netxms.org/raspian (from http://packages.netxms.org/debian).

We use event processing policies to process the event, run the event through the filter script which uses sha1() on the relevant data/variable to get a hash and pass it to the CUSTOM_MESSAGE variable, which can be referenced as %M as part of the alarm key.

We hit that a while ago, but technically just increasing the allowed size of the key wouldn't solve the problem. At some point someone would end up wanting a 1024 character key. Or 65000. So that's probably more of a documentation issue.
Our solution was to create a hash instead of passing a long message along as a key.
So in your case, instead of using %4 as is you would use a script to return the value of sha1(%4).

I am pretty sure the event description (just like the names of the varbinds) is more like a "comment" field.
Though I guess if you wanted to, you could create a script that pulls the relevant data out of the NetXMS database via an action called on the agent on the NetXMS server itself, then call that script as part of your processing policy?

My SNMP Trap setup is very limited at present, but I did run into a few stumbling blocks like lack of transform scripts (so I could translate the values of each varbind into something human-readable as required). Automatically pulling available information from the MIB would be a great start, but I'd still like to be able to add my own "spin" on the returned values.

When I first started with traps, I created one event per trap and just returned whatever the trap gave me. That was quite an undertaking and in the end meant wasn't helpful to technicians reading logs who had no idea what the values translated to.
Lately I've been moving towards attempting to create more generic events and using event processing policy filter scripts to adjust the event after the fact. That does for example allow me to change event severity depending on a varbind value or transform numerical status values into human-readable strings. However, that also comes with a downside. Once a device is in maintenance mode, event processing rules aren't parsed anymore, which means all that processing logic is completely ignored during that period. For most of our devices sending traps, that's a non-issue as they are never set to maintenance mode, but there are a few exceptions.

Lenovo XClarity / IBM Integrated Management Console SNMP Traps Template

The traps all contain the same varbinds. The trap configuration in this template pick out the following:
- Datetime
- Priority
- Message Text
- Message ID Prefix

The Event includes the Datetime, Prefix and Message Text.
Priority is read inside the Event Processing policy, which changes the Events severity as needed. The policy is effectively used as "SNMP Trap Transform Script".

No policy for alerting is included, but that could be done inside the included policy or by adding another one below it (processing does not stop at the transform policy).

When you click on "Entire Network", what's the ID of the Object?
It should (and the script expects it to) be "1" but if for some odd reason it isn't, that'd be a problem.

UniFi Switch SNMP Template

Applies to:
- Systems with SNMP Object ID .1.3.6.1.4.1.4413 and system description starting with "USW-".

Notes:
- We are monitoring only one of these and the above looks like it should work for other UniFi switches if this one device is anything to go by. Problem with .1.3.6.1.4.1.4413 is that it is the Broadcom Enterprise, so could potentially be matching a lot of other devices if it wasn't for the additional system description restriction. As all data for the UniFi switch is also located in the Broadcom Enterprise, this could maybe be turned into a more generic Broadcom template (someone with matching devices would be able to confirm this).

TP Link Switch SNMP Template

Applies to:
- Systems with SNMP Object ID matching .1.3.6.1.4.1.11863.5.*

Note:
- We only monitor one of these and it's not returning a lot of data (that we found useful from a monitoring perspective), so the template is fairly simple.

Ruckus Brocade ICX SNMP Template

Applies to:
- Systems with SNMP Object ID matching .1.3.6.1.4.1.1991.*, but not .1.3.6.1.4.1.1991.1.3.52.2.4.1.1.

SonicWALL SNMP Template

Applies to:
- Systems with SNMP Object ID .1.3.6.1.4.1.8741.1

Note:
- The Concurrent Connections % is a scripted DCI, the device itself does not provide a direct % for alerting. The DCI does not rely on the Maximum and Current DCIs, but collects both values independently via SNMP. If you have a range of these devices, it's probably worth changing the script.

WatchGuard Firewall SNMP Template

Applies to:
- Systems with SNMP Object ID matching .1.3.6.1.4.1.3097.* (WatchGuard Template)
- Systems with SNMP Object ID matching .1.3.6.1.4.1.3097.* and a valid response for SNMP OID .1.3.6.1.4.1.3097.6.6.1.0 (WatchGuard FireCluster Template)

Note:
- The Used RAM % is a scripted DCI, the device itself does not provide a direct % for alerting. The DCI does not rely on the Installed/Free RAM DCIs, but collects both values independently via SNMP. If you have a range of these devices, it's probably worth changing the script.

Also attached a separate template with a simple SNMP Trap for Alerts triggered by WatchGuards. Every alert triggers the same trap.
Configuring alerts via SNMP Traps is a bit of a pain in Watchguards, as you need to enable SNMP, configure the destination and enable alerts in every little service/proxy/whatever you might want to get alerts for..

As you are using a script DCI that goes through every single node in your installation, you can put that DCI on any node, really.
You could create a dummy node, e.g. "AWS" and create the DCI on there.

Based on your error, it doesn't like something (the rootObject?) in line
foreach(o : GetObjectChildren(rootObject))

As per the script, initially that'd get the object children of object 1 (which is "Entire Network") and then move down the tree.
I wouldn't think this could break unless there is a typo in the script (direct copy&paste without a single change worked without any issues for me on two different installs) or some kind of database corruption. But Victor might have an idea.

Script works fine on my system. Did you copy&paste or type it?
The reason the script uses FileSystem.Used(*) is because the * in the script is a wildcard, so it catches all such DCIs. It is not the same as an actual DCI on a node.

To create a script DCI, create a new DCI and select Script under Origin. As Parameter you use the name of the script in your Script Library (see attached example for a script called "DCI::GetIPAddresses", obviously yours will be called something else).

You haven't configured a log file as such.
It's possible the error message is misleading. {syslog} on Windows means it will log to the Windows Event Log, not a file.

If you want an actual log file, you would need to enter the full path/filename, e.g.
LogFile = C:\NetXMS\nxagentd.log

Containers for Unmanaged nodes suffer from a small problem: Auto-Bind rules are applied during a configuration poll and configuration polls don't run against unmanaged nodes.
You'd probably have to write a separate script and run it on a schedule to make this work. $node->status returns "6" for unmanaged nodes.

In regards to disabled DCIs, I guess you could use a script similar to this:
dciArray = FindAllDCIs($node,"*");
for (dci : dciArray) {
if (dci->status == 1) return true;
}

Now, the above will be true if there is any DCI on that node that's disabled. If you want to test for a specific one, you'll have to adjust the script accordingly.