Does anybody have the following templates that they would like to share?

Proxmox VE
OPNsense

Many thanks,

Alex

Notes:

Instance discovery on attached sensors.

CoromaticUPS.xml

Notes: Instance discover on attached sensors and grab name from device

AKCP_sensorProbe2.xml

See attached screenshots for examples.
To make things easier, add the datastore names as persistant storage keys and values.
You can then reference them in the scripts using the name rather than the annoyingly long mount points. Of course there's no easy way of finding out this in the first place, other than SSHing into the server and doing a "df", or looking in the vCenter DataStore sections. Datastore names are not queryable via SNMP as far as I can tell, which is lame.

The template should auto apply, but once they have applied to your servers, you will need to add some DCIs manually using the included scripts to correctly deal with the datastores.
The getVMWareCPULoad(totalCPUUsage) is used to monitor total CPU usage for all cores, as with most VMWare servers, graphing individual CPUs will probably end up with a crazy graph with mainly black lines unless you can be bothered to find 32 different colours for your 32 cores

getVMWareCPULoad

 will add up CPU usage from each core, and using getVMWareCPULoad(totalCPUCountX100) can be used to get a line to show if all cores were using 100%.

Hopefully this is useful. If you have any suggestions on how to add more useful metrics, please let me know!
Thanks

VMWareESXi7.xml

Note, this should also work for mono Lasers, but you might have to delete some DCIs.
I took the values from my HP Color LaserJet M254dw

The next thing to add to this would be to get the graphs to automatically display the right legend for each toner cartridge.
I tried to follow https://www.netxms.org/forum/general-support/is-it-possible-to-use-text-from-another-snmp-attribute-for-the-legend-on-graphs/msg30369/#msg30369, but still don't understand it

Let me know if you can think of any improvements as this is my first successful attempt

HPColorLaserJets.xml

Well - here is the first cut of my Windows generic template. it includes the events that are triggered.

For explanation of the thresholds that apply in this template, they are implemented as per here:
https://www.netxms.org/forum/general-support/simple-question-cdm-monitoring-using-snmp-anybody-doing-this/msg25843/#msg25843

For excluding CD drives in discovery you have to exclude UFS as well...

Best regards,
Victor

Cisco template

• cpu load
• memory utilization
• hardware monitoring

I downloaded this template, successfully imported it into NetXMS (v3.4.178), and it's automatically applying to my Cisco 1841 ISR router, but there are no DCIs when the xml template gets imported. Any ideas?

cisco.xml

please advice

Applies to:

• A range of devices with Ubiquiti-style messy OIDs depending on firmware versions (things changed with firmware version 3.9.19):
    - Devices with SNMP Object ID .1.3.6.1.4.1.10002.1 or SNMP Object ID like .1.3.6.1.4.1.41112.* if a valid result is returned for OID .1.3.6.1.4.1.41112.1.6.3.1.
    - Devices with SNMP Object ID .1.3.6.1.4.1.8072.3.2.10 if a valid result is return for OI .1.3.6.1.4.1.41112.1.6.3.1.0.
    - The Ubiquiti template applies to anything with either 10002 or 41112 match as well as 8072. In case of the latter, the system description also needs to start with UAP.

Notes:

• The pre/post 3.9.19 UniFi templates included in the XML both collect the exact same data. They only cater for the fact that Ubiquiti decided to change the OIDs used.

Ubiquiti.xml

Applies to:

• Devices with SNMP Object ID .1.3.6.1.4.1.10002.1 (Frogfoot MIB, which Ubiquiti at some point decided to use before they got their own Enterprise OID) or SNMP Object ID like .1.3.6.1.4.1.41112.* (Ubiquiti's own OID). Devices must also have a valid entry for OID .1.3.6.1.4.1.41112.1.4.1.1.9.1 (i.e. must have an antenna registered)

Notes:

• Just to avoid potential disappointment: This is not a template for Unifi Access Points. It is for AirMAX wireless bridges.

Ubiquiti AirMAX.xml

Applies to:

• Systems with SNMP Object ID .1.3.6.1.4.1.25053.3.1.5.*

Note:

• Unnamed WAPs in ZoneDirector will show up with the same instance name, making it difficult to tell them apart. It is recommended to ensure they all have proper names.

Ruckus ZoneDirector.xml

Applies to:

• Systems with SNMP Object ID .1.3.6.1.4.1.21013.1.*

Notes:

• Default SNMP Community for Xirrus access points is xirrus.

Xirrus.xml

Applies to:

• Systems with SNMP Object ID .1.3.6.1.4.1.9.1.* and a valid entry in the .1.3.6.1.4.1.9.9.661.1.1.1.1 table.

Cisco Cellular.xml

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).

SNMP Traps - Lenovo XCC, IBM IMM.xml

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).

UniFi Switch.xml

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.

TP Link.xml

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.

Ruckus Brocade ICX.xml

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.

SonicWALL.xml

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..

WatchGuard.xml

WatchGuard SNMP Trap.xml

Applies to:

• Systems with SNMP Object ID matching .1.3.6.1.4.1.24681.* and a valid response for SNMP OID .1.3.6.1.4.1.24681.1.4.1.1.1.1.4.2.0. (QNAP NAS Template)
• Systems with SNMP Object ID matching .1.3.6.1.4.1.24681.* and no valid response for SNMP OID .1.3.6.1.4.1.24681.1.4.1.1.1.1.4.2.0. (QNAP NAS (old) Template)

Notes:
I am unsure at which firmware version the new MIB kicked in. It also appears some older models even with the latest firmware are still using the old MIB. The extra check for the OID above seems to work well for identification though.

Also attached a separate template with three QNAP SNMP Traps (QNAP appears to simply send Inform/Warning/Error traps with different messages) and matching events.

QNAP NAS.xml

QNAP SNMP Traps.xml