[prev in list] [next in list] [prev in thread] [next in thread]
List: net-snmp-users
Subject: RE: perl pass_persist && getnext/getbulk - no end of MIB
From: Jurkiewicz Jean-Marc <Jean-Marc.Jurkiewicz () manor ! ch>
Date: 2015-07-13 7:19:09
Message-ID: 2b53685ac54345e08ca55234e22b1c5d () BAZV520 ! manor ! ch
[Download RAW message or body]
Hi all,
GETBULK always fills the returned buffer, so if your request does not completely \
"fill" the returned buffer, the agent will read further in the OID tree to fill the \
buffer.
(please have a look at http://jmjmon.eu/LaSupervisionDeReseau/SNMP_Mon-V010.pdf page \
74 and further)
> From my understanding, the problem does not come from GETBULK, either from \
> snmptable that do not "clean-up" the "overhead " used to fill the buffer.
When I use GETBULK I always (see same URL page 81 and 115) check that the last \
returned information is an answer to the requested OID, and not used-to-fill \
information.
Hope this helps
Best regards
JMJ
-----Message d'origine-----
De : Turbo Fredriksson [mailto:turbo@bayour.com]
Envoyé : dimanche 12 juillet 2015 21:46
À : net-snmp-users@lists.sourceforge.net
Objet : perl pass_persist && getnext/getbulk - no end of MIB
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
------------------------------------------------------------------------------
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic