I've been fixing some issues with my MIB (or at least tried to, see the "Integer64 support" thread).
In doing so, I discovered some minor issues and one that's … "irritating". The log file is from the output of the pass_persist script (https://github.com/FransUrbo/snmp-modules/blob/master/zfs/zfs-snmp-stats.pl) ----- s n i p ----- DebianZFS-Jessie64-Devel-Daily:/usr/src# snmpwalk -uro -v2c -cpublic localhost zfsPoolStatusTable BAYOUR-COM-MIB::zfsPoolStatusIndex.1 = INTEGER: 1 BAYOUR-COM-MIB::zfsPoolStatusIndex.2 = INTEGER: 2 BAYOUR-COM-MIB::zfsPoolName.1 = STRING: rpool BAYOUR-COM-MIB::zfsPoolName.2 = STRING: rpool 2 BAYOUR-COM-MIB::zfsPoolGUID.1 = STRING: 4977845871582736322 BAYOUR-COM-MIB::zfsPoolGUID.2 = STRING: 3787144349319647945 BAYOUR-COM-MIB::zfsPoolSize.1 = Opaque: Int64: 8256506880 BAYOUR-COM-MIB::zfsPoolSize.2 = Opaque: Int64: 8256506880 BAYOUR-COM-MIB::zfsPoolAlloc.1 = INTEGER: 132096 BAYOUR-COM-MIB::zfsPoolAlloc.2 = INTEGER: 111616 BAYOUR-COM-MIB::zfsPoolFree.1 = Opaque: Int64: 8256374784 BAYOUR-COM-MIB::zfsPoolFree.2 = Opaque: Int64: 8256395264 BAYOUR-COM-MIB::zfsPoolCap.1 = INTEGER: 0 BAYOUR-COM-MIB::zfsPoolCap.2 = INTEGER: 0 BAYOUR-COM-MIB::zfsPoolDedup.1 = STRING: 1.00 BAYOUR-COM-MIB::zfsPoolDedup.2 = STRING: 1.00 BAYOUR-COM-MIB::zfsPoolHealth.1 = INTEGER: online(4) BAYOUR-COM-MIB::zfsPoolHealth.2 = INTEGER: online(4) BAYOUR-COM-MIB::zfsPoolAltRoot.1 = STRING: - BAYOUR-COM-MIB::zfsPoolAltRoot.2 = STRING: - BAYOUR-COM-MIB::zfsPoolUsedBySnaps.1 = INTEGER: 0 BAYOUR-COM-MIB::zfsPoolUsedBySnaps.2 = INTEGER: 0 BAYOUR-COM-MIB::zfsPoolUsed.1 = INTEGER: 282624 BAYOUR-COM-MIB::zfsPoolUsed.2 = INTEGER: 111616 DebianZFS-Jessie64-Devel-Daily:/usr/src# egrep '[0-9] \.[0-9]' /tmp/zfs-snmp.log 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.1.1 = 1 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.1.2 = 22015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.2.1 = rpool 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.2.2 = rpool 2 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.3.1 = 4977845871582736322 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.3.2 = 3787144349319647945 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.4.1 = 8256506880 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.4.2 = 8256506880 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.5.1 = 132096 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.5.2 = 111616 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.6.1 = 8256374784 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.6.2 = 8256395264 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.7.1 = 0 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.7.2 = 0 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.8.1 = 1.00 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.8.2 = 1.00 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.9.1 = ONLINE 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.9.2 = ONLINE 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.10.1 = - 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.10.2 = - 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.11.1 = 0 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.11.2 = 0 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.12.1 = 282624 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.12.2 = 111616 2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.6.1.1.1 = 1 DebianZFS-Jessie64-Devel-Daily:/usr/src# ----- s n i p ----- Here a "snmpwalk" work just fine. It outputs the whole zfsPoolStatusTable and as soon as "snmpwalk" finds the first entry of the next branch, it cancels (?) the continuing requests. However: ----- s n i p ----- DebianZFS-Jessie64-Devel-Daily:/usr/src# snmptable -uro -v2c -cpublic localhost zfsPoolStatusTable SNMP table: BAYOUR-COM-MIB::zfsPoolStatusTable zfsPoolName zfsPoolGUID zfsPoolSize zfsPoolAlloc zfsPoolFree zfsPoolCap zfsPoolDedup zfsPoolHealth zfsPoolAltRoot zfsPoolUsedBySnaps zfsPoolUsed rpool 4977845871582736322 8256506880 132096 8256374784 0 1.00 online - 0 282624 rpool 2 3787144349319647945 8256506880 111616 8256395264 0 1.00 online - 0 111616 BAYOUR-COM-MIB::zfsPoolStatusTable: WARNING: More columns on agent than in MIB DebianZFS-Jessie64-Devel-Daily:/usr/src# egrep '[0-9] \.[0-9]' /tmp/zfs-snmp.log2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.1.1 = 1 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.1.2 = 2 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.2.1 = rpool 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.2.2 = rpool 2 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.3.1 = 4977845871582736322 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.3.2 = 3787144349319647945 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.4.1 = 8256506880 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.4.2 = 8256506880 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.5.1 = 132096 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.5.2 = 111616 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.6.1 = 8256374784 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.6.2 = 8256395264 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.7.1 = 0 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.7.2 = 0 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.8.1 = 1.00 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.8.2 = 1.00 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.9.1 = ONLINE 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.9.2 = ONLINE 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.10.1 = - 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.10.2 = - 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.11.1 = 0 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.11.2 = 0 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.12.1 = 282624 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.12.2 = 111616 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.1.1 = 1 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.2.1 = 1198736 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.3.1 = 1194848 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.4.1 = 393386496 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.5.1 = 524515328 2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.6.1 = 1194848 ----- s n i p ----- Here, "snmptable" claims that there's more columns, not part of the MIB. But they're really not part of that table. But why isn't "snmptable" stops when it receives the ".1.3.6.1.4.1.8767.2.6.6.1.1.1" entry like "snmpwalk" do (I only have one entry/line in the next table, the zfsARCUsageTable)? And this is the same of ALL my tables. If I add "-CB" to the "snmptable" command it works… Is there a special "END OF MIB" entry I need to output to make it know that it's done? I tried "NONE\n", but that didn't work. Tried "END\n" as well, but no luck there either… I guess, from finding the "-CB" option in the manpage, that the "problem" have something to do with GETBULK... -- Life sucks and then you die ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
