[collectd] I don't know the ASN type #130
Mark
gajillion at gmail.com
Tue Sep 11 17:52:25 CEST 2012
Sorry to reply to my own thread. I've been digging into this further and
there seems to be something wrong in the way that the Instance/Subtree
iterator is working. Apologies for the std_traffic example - it works fine
now - but it highlights the issue.
Here's a dump of the example below of std_traffic (truncated for space),
and the plugin working properly:
Q: interfaces.ifTable.ifEntry.ifInOctets
interfaces.ifTable.ifEntry.ifOutOctets interfaces.ifTable.ifEntry.ifDescr
R: interfaces.ifTable.ifEntry.ifInOctets.1=3774870817
interfaces.ifTable.ifEntry.ifOutOctets.1=3774870817
interfaces.ifTable.ifEntry.ifDescr.1="lo"
Q: interfaces.ifTable.ifEntry.ifInOctets.1
interfaces.ifTable.ifEntry.ifOutOctets.1
interfaces.ifTable.ifEntry.ifDescr.1
R: interfaces.ifTable.ifEntry.ifInOctets.2=1268816808
interfaces.ifTable.ifEntry.ifOutOctets.2=1391460740
interfaces.ifTable.ifEntry.ifDescr.2="eth0"
Q: interfaces.ifTable.ifEntry.ifInOctets.2
interfaces.ifTable.ifEntry.ifOutOctets.2
interfaces.ifTable.ifEntry.ifDescr.2
R: interfaces.ifTable.ifEntry.ifInOctets.3=0
interfaces.ifTable.ifEntry.ifOutOctets.3=0
interfaces.ifTable.ifEntry.ifDescr.3="eth1"
Q: interfaces.ifTable.ifEntry.ifInOctets.3
interfaces.ifTable.ifEntry.ifOutOctets.3
interfaces.ifTable.ifEntry.ifDescr.3
R: interfaces.ifTable.ifEntry.ifInUcastPkts.1=32813168
interfaces.ifTable.ifEntry.ifOutUcastPkts.1=32813168
interfaces.ifTable.ifEntry.ifType.1=24
As you can see, all three values iterate through their trees until they
reach ifInUcastPkts, ifOutUcastPkts, and ifType respectively. The plugin
correctly recognizes that the subtree has been exited and quits.
Now here's the netscaler configuration:
<Data "ns_vservers">
Type "ns_vserver"
Table true
Instance "SNMPv2-SMI::enterprises.5951.4.1.3.1.1.1" # Indexed by
virtual server name
Values "SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43" # traffic per
vserver
</Data>
And here's what I see from the dump (truncated)
Q: E:5951.4.1.3.1.1.43 E:5951.4.1.3.1.1.1
R:
E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80="27178"
E:5951.4.1.3.1.1.1.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80="VSERVER-1"
Q: E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80
E:5951.4.1.3.1.1.1.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80
R:
E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80="27204"
E:5951.4.1.3.1.1.1.16.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80="VSERVER-2"
Q: E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80
E:5951.4.1.3.1.1.1.16.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80
R:
E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80="27204"
E:5951.4.1.3.1.1.1.19.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80.45.67.83="VSERVER-3"
Q: E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80
E:5951.4.1.3.1.1.1.19.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80.45.67.83
As you can see, the "5951.4.1.3.1.1.1" values are being iterated through,
but the "5951.4.1.3.1.1.43" receives its first response:
R:
E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80="27178"
Queries with it, receives a different response (as expected)
R:
E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80="27204"
But then, goes back and continues to requery with the first response:
Q: E:5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80
This continues, well... forever. The Instance MIB keeps iterating and
iterating until it's way out if its tree, but the Value MIB insists on
querying the initial value it received. The plugin gets stuck in a loop and
never logs any data.
Any help would be appreciated.
Mark
On Fri, Sep 7, 2012 at 2:21 PM, Mark <gajillion at gmail.com> wrote:
> Thanks Octo - I'm still having issues though and I'm beginning to wonder
> if it's my implementation or a larger issue. I reduced my config to the
> standard table example in the default configuration:
>
> <Data "std_traffic">
> Type "if_octets"
> Table true
> Instance "IF-MIB::ifDescr"
> Values "IF-MIB::ifInOctets" "IF-MIB::ifOutOctets"
> </Data>
>
> <Host "myhost">
> Address "myhost"
> Version 2
> Community "communitystring"
> Collect "std_traffic"
> </Host>
>
> This simple configuration doesn't work. If my understanding is correct,
> "Instance" provides an iterator of sorts which is then used to get the
> values listed in "Values". tcpdump tells me all the calls are being done at
> once:
>
> 11:07:07.416822 IP collectd_server.48042 > myhost.snmp: C=communitystring
> GetNextRequest(59) interfaces.ifTable.ifEntry.ifInOctets
> interfaces.ifTable.ifEntry.ifOutOctets interfaces.ifTable.ifEntry.ifDescr
>
> As expected, this returns the first interface's information (as verified
> by a manual snmpgetnext):
>
> IF-MIB::ifInOctets.1 = Counter32: 3740191310
>
> Since the box has 3 interfaces, (lo, eth0, eth1), in my thinking this
> process should repeat 2 more times, which it does:
>
> 11:07:07.420375 IP myhost.snmp > collectd_server.48042: C=communitystring
> GetResponse(74) interfaces.ifTable.ifEntry.ifInOctets.1=3739077099
> interfaces.ifTable.ifEntry.ifOutOctets.1=3739077099
> interfaces.ifTable.ifEntry.ifDescr.1="lo"
> 11:07:07.420816 IP collectd_server.48042 > myhost.snmp: C=communitystring
> GetNextRequest(62) interfaces.ifTable.ifEntry.ifInOctets.1
> interfaces.ifTable.ifEntry.ifOutOctets.1
> interfaces.ifTable.ifEntry.ifDescr.1
> 11:07:07.422980 IP myhost.snmp > collectd_server.48042: C=communitystring
> GetResponse(76) interfaces.ifTable.ifEntry.ifInOctets.2=3561114835
> interfaces.ifTable.ifEntry.ifOutOctets.2=4032830435interfaces.ifTable.ifEntry.ifDescr.2="eth0"
> 11:07:07.423126 IP collectd_server.48042 > myhost.snmp: C=communitystring
> GetNextRequest(62) interfaces.ifTable.ifEntry.ifInOctets.2
> interfaces.ifTable.ifEntry.ifOutOctets.2
> interfaces.ifTable.ifEntry.ifDescr.2
> 11:07:07.425329 IP myhost.snmp > collectd_server.48042: C=communitystring
> GetResponse(68) interfaces.ifTable.ifEntry.ifInOctets.3=0
> interfaces.ifTable.ifEntry.ifOutOctets.3=0
> interfaces.ifTable.ifEntry.ifDescr.3="eth1"
>
>
> Now, when I do an snmpwalk on those MIBs, that's where it ends:
>
> # snmpwalk -v 2c -c communitystring myhost IF-MIB::ifInOctets
> IF-MIB::ifInOctets.1 = Counter32: 3740192294
> IF-MIB::ifInOctets.2 = Counter32: 3775550612
> IF-MIB::ifInOctets.3 = Counter32: 0
> #
>
> I understand that GetNextRequest has no way of knowing that this is the
> end of the MIB so the next call is expected:
>
> 11:07:07.425426 IP collectd_server.48042 > myhost.snmp: C=communitystring
> GetNextRequest(62) interfaces.ifTable.ifEntry.ifInOctets.3
> interfaces.ifTable.ifEntry.ifOutOctets.3
> interfaces.ifTable.ifEntry.ifDescr.3
> 11:07:07.427585 IP myhost.snmp > collectd_server.48042: C=communitystring
> GetResponse(71) interfaces.ifTable.ifEntry.ifInUcastPkts.1=32690775
> interfaces.ifTable.ifEntry.ifOutUcastPkts.1=32690775
> interfaces.ifTable.ifEntry.ifType.1=24
>
> However, it seems to me that once it receives that data, it should stop
> because we're out of the ifInOctets subtree altogether now. Instead, it
> keeps going:
>
> 11:07:07.427790 IP collectd_server.48042 > myhost.snmp: C=communitystring
> GetNextRequest(62) interfaces.ifTable.ifEntry.ifInOctets.3
> interfaces.ifTable.ifEntry.ifOutOctets.3 interfaces.ifTable.ifEntry.ifType.1
> 11:07:07.429960 IP myhost.snmp > collectd_server.48042: C=communitystring
> GetResponse(71) interfaces.ifTable.ifEntry.ifInUcastPkts.1=32690775
> interfaces.ifTable.ifEntry.ifOutUcastPkts.1=32690775
> interfaces.ifTable.ifEntry.ifType.2=6
> 11:07:07.430062 IP collectd_server.48042 > myhost.snmp: C=communitystring
> GetNextRequest(62) interfaces.ifTable.ifEntry.ifInOctets.3
> interfaces.ifTable.ifEntry.ifOutOctets.3 interfaces.ifTable.ifEntry.ifType.2
> 11:07:07.432313 IP myhost.snmp > collectd_server.48042: C=communitystring
> GetResponse(71) interfaces.ifTable.ifEntry.ifInUcastPkts.1=32690775
> interfaces.ifTable.ifEntry.ifOutUcastPkts.1=32690775
> interfaces.ifTable.ifEntry.ifType.3=6
>
> It keeps crawling the tree and never returns so I get no data. If I wait
> long enough, I can see it climbing up the processor tree...
>
> 11:09:01.595140 IP myhost.snmp > collectd_server.60949: C=communitystring
> GetResponse(115) interfaces.ifTable.ifEntry.ifInUcastPkts.1=32694434
> interfaces.ifTable.ifEntry.ifOutUcastPkts.1=32694434
> 25.3.2.1.3.768="GenuineIntel: Intel(R) Xeon(TM) CPU 3.20GHz"
> 11:09:01.595335 IP collectd_server.60949 > myhost.snmp: C=communitystring
> GetNextRequest(64) interfaces.ifTable.ifEntry.ifInOctets.3
> interfaces.ifTable.ifEntry.ifOutOctets.3 25.3.2.1.3.768
> 11:09:01.596967 IP myhost.snmp > collectd_server.60949: C=communitystring
> GetResponse(115) interfaces.ifTable.ifEntry.ifInUcastPkts.1=32694434
> interfaces.ifTable.ifEntry.ifOutUcastPkts.1=32694434
> 25.3.2.1.3.769="GenuineIntel: Intel(R) Xeon(TM) CPU 3.20GHz"
> 11:09:01.597084 IP collectd_server.60949 > myhost.snmp: C=communitystring
> GetNextRequest(64) interfaces.ifTable.ifEntry.ifInOctets.3
> interfaces.ifTable.ifEntry.ifOutOctets.3 25.3.2.1.3.769
> 11:09:01.598697 IP myhost.snmp > collectd_server.60949: C=communitystring
> GetResponse(115) interfaces.ifTable.ifEntry.ifInUcastPkts.1=32694434
> interfaces.ifTable.ifEntry.ifOutUcastPkts.1=32694434
> 25.3.2.1.3.770="GenuineIntel: Intel(R) Xeon(TM) CPU 3.20GHz"
> 11:09:01.598890 IP collectd_server.60949 > myhost.snmp: C=communitystring
> GetNextRequest(64) interfaces.ifTable.ifEntry.ifInOctets.3
> interfaces.ifTable.ifEntry.ifOutOctets.3 25.3.2.1.3.770
>
> Any ideas what might be going on here? Thanks,
>
> Mark
>
>
>
>
>
> On Fri, Sep 7, 2012 at 1:46 AM, Florian Forster <octo at collectd.org> wrote:
>
>> Hi Mark,
>>
>> thanks for your detailed information. I've added an appropriate check to
>> the SNMP plugin, see <http://octo.cx/07739da>. I've committed this to
>> the collectd-4.10 branch, so it'll appear in the next bugfix releases.
>>
>> Best regards,
>> —octo
>> --
>> collectd – The system statistics collection daemon
>> Website: http://collectd.org
>> Google+: http://collectd.org/+
>> GitHub: https://github.com/collectd
>> Twitter: http://twitter.com/collectd
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20120911/ce9a83a3/attachment.html>
More information about the collectd
mailing list