I don’t know if this was your situation… but is this host across a router on another subnet?
I ask because I had this exact problem with ZFS. I have three machines running ZFS and one of them had completely blank ZFS graphs despite successfully discovering the application (yes, I had put in the zfs-linux snmp script and extended properly). Drove me nuts until I finally used
snmpget -v2c -c public -Oqv -m NET-SNMP-EXTENDED-MIB udp:hostname:161 nsExtendedOutputFull.188.8.131.52
I got the response “Timeout: No Response from udp:hostname:161”. As a test I enabled tcp and switched LibreNMS to use TCP for SNMP on that host and voila; data started coming in. I know you’d need a different command, but this is just for reference.
While everything else seemed to be working across UDP (including my NFS statistics), it was specifically the ZFS stats that weren’t coming back across UDP. I don’t really know why offhand but this was an easily solution that hasn’t resulted in any notable issues. I suspect it is something in the zfs-linux script or the system that it just doesn’t like for some reason.
Thanks… interesting stuff. I will say that the time taken for a response from the affected host is longer than I’d expect when I run that same command from a host on the same subnet; something on the order of about 3 seconds before I get data back. But I do think there’s something there with a timeout across my router but not 100% sure where the problem may be coming from.
My network setup is pretty simple; my inter-VLAN router is an L3 switch (Dell N4064)… the LibreNMS host is hung off a simple L2 switch in a different location with a simple gig connection between the two.
It does seem specifically to be related to applications / snmp extensions. All the basic SNMP stuff seems to be coming back without issue.