Subject: SNMP custom checks do not reach agentless devices—but inventory does
I’m testing octoja and integrating agentless devices—starting with a Synology RackStation and a NetApp storage device, and later adding switches, firewalls, and ESXi hosts. In the process, I’ve encountered behavior that I can’t explain. This raises three issues.
1. Custom checks in SNMP mode apparently do not use the monitoring proxy
Both devices are located on a customer’s LAN behind a firewall and are not accessible from the outside. A server on the same network is configured as the monitoringAsset.
Agentless inventory works flawlessly this way—asset “Synology RS,” agentlessInventoryAt 12:22:11, agentlessData.snmp fully populated: Model RS3621RPxs, DSM 7.3-86009, systemStatus, powerStatus, and both fan values “Normal,” updateStatus UpToDate, temperature 36 °C, 14 disks, 2 volumes, 9 interfaces.
The custom check on the same asset, using the same community, five minutes earlier (12:17:45): checkResult 3, errorMessage: snmp_unreachable. The same issue with the NetApp.
Cross-check directly on the server configured as a proxy: an SNMPv2c GET request to 1.3.6.1.2.1.1.1.0 is answered by both devices. The network path is clear, the community is correct, and the configuration on the asset is also correct.
To me, this looks like the check isn’t running through the configured peer, but is instead attempting to reach the destination address from a different location—and, naturally, a private customer network isn’t accessible from there. My request: Run SNMP custom checks via the same path as the agentless inventory, i.e., via the ` monitoringAsset` stored on the asset.
2. Error messages with source information
`snmp_unreachable` does not specify which peer made the request, what the source address was, what the timeout was—or even whether a packet was sent at all. Without this information, the error cannot be narrowed down from the outside; I had to recreate the path using my own scripts on the proxy just to know where to look.
It would be better to include the following in the error message or check result: the peer that sent the request, the destination address and port, the SNMP version, the timeout, and whether there was no response or the community was rejected.
3. Analysis of the Inventory Values Already Recorded
The values that matter for a NAS are already present in the dataset—system status, fans, disk and volume status, temperature, and capacity. However, they are only displayed as-is. I’d like to set thresholds and alarms for them without having to build a separate check each time.
For NetApp/ONTAP, the inventory currently provides only MIB-II (sysDescr, runtime, one interface); the “hardware” and “nas ” fields remain empty. A manufacturer-specific evaluation would be necessary here—for an ONTAP cluster, the relevant values would be aggregate capacity, disk and shelf status, failover status, and SnapMirror lag. If standard checks for NAS, switches, firewalls, and ESXi were included, that would be the point at which I could completely remove my agentless devices from the legacy system.