[collectd] I don't know the ASN type #130
Mark
gajillion at gmail.com
Tue Sep 11 21:18:17 CEST 2012
Ah! I'm pretty sure I've found the issue.
In csnmp_read_table, there is the following comparison:
if ((value_table_ptr[i] != NULL)
&& (vb->name[vb->name_length - 1] <= value_table_ptr[i]->subid))
{
DEBUG ("snmp plugin: host = %s; data = %s; i = %i; "
"SUBID is not increasing.",
host->name, data->name, i);
continue;
}
This makes the (what appears to be invalid) assumption that while walking a
subtree, the last entry of the SUBID will always be incremented to indicate
the SUBID is increasing. This is not necessarily the case. In fact, I don't
think you can even make an assumption about which value of the OID will
always be increasing. An SNMP walk of the example below shows the OID
increasing first at SUBID 7, then 8, 18, back to 8, then 8, then 30.
snmpwalk -v 2c -c communitystring target
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80
= STRING: "30569"
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43.16.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80
= STRING: "30585"
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43.19.83.78.86.45.82.84.66.45.66.117.115.45.72.84.84.80.45.67.83
= STRING: "30585"
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43.23.83.78.86.45.82.84.66.45.83.97.110.100.98.111.120.45.72.84.84.80.45.67.83
= STRING: "0"
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.43.23.83.78.86.45.82.84.66.45.83.97.110.100.98.111.120.45.72.84.84.80.45.86.83
= STRING: "0"
That's where snmpwalk stops. An snmpgetnext on that last OID gives the
following response:
SNMPv2-SMI::enterprises.5951.4.1.3.1.1.44.16.83.78.86.45.82.84.66.45.66.105.100.45.72.84.84.80
= STRING: "478439694"
_Now_ we're in a different SUBID because of the change on 7 from "43" to
"44". However, since the code is checking for vb->name[vb->name_length - 1]
<= value_table_ptr[i]->subid, we never get past the second and third
snmpgetnext calls because they both end in the same subid, "80". In other
words, we can definitely assert that should vb->name[vb->name_length - 1] >
value_table_ptr[i]->subid, then the SUBID has changed. However, we can't
conversely assume that just because vb->name[vb->name_length - 1] ==
value_table_ptr[i]->subid, the SUBID has not changed.
So instead of checking for only the last subid, it seems like we should be
doing something like (pseudo-code):
increasing = false;
for(i = 0; i < length_of_oid && !increasing; i++){
if(new_oid[i] > old_oid[i]){
increasing = true;
}
}
if(!increasing){
WARNING ("snmp plugin: host = %s; data = %s; i = %i; "
"SUBID is not increasing.",
host->name, data->name, i);
continue;
}
The biggest problem I see is that we're only saving "subid" which is the
last value of a very long string we need to check. I'm not comfortable
changing the entire value_table_ptr structure so we can save the required
OID information.
Mark
On Tue, Sep 11, 2012 at 8:52 AM, Mark <gajillion at gmail.com> wrote:
> 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/8ecd9352/attachment-0001.html>
More information about the collectd
mailing list