[hobbit] hobbit_snmpcollect

[Henrik Stoerner]

On Wed, Oct 03, 2007 at 01:37:37PM +0200, Lars Ebeling wrote:
> I want to learn about snmp, so I downloaded the source to 
> net-snmp 5.4.1 and installed it. Now I want to test hobbit_snmpcollect.
> 
> How is it run and what do I expect to see.
> 
> I configured  hobbit_snmpcollect.cfg like this: (copied from Henriks mail)
> 
> [localhost]                                                
> version=1                                                  
> community=public                                           
> mrtg=2 IF-MIB::ifInOctets.2 IF-MIB::ifOutOctets.2 Main IO  
> # ifmib=2 LAN                                              
> # ifmib=(eth0) LAN                                         
> # ifmib=[0:e:a6:ce:d6:85] LAN                              
> ifmib={leopg9.no-ip.org} LAN                               
> 
> This is what I get when I run hobbit_snmpcollect from commandline:
>  
> [Main IO]
> 	ds1 = 2908625400
> 	ds2 = 2908625400

As I'd expect.

An introduction to SNMP is really out-of-scope for this mailing list,
you can probably find some information on the net. I can give you a
quick run-down:

Data in SNMP is structured hierarchially. An entry in the hierarchy is 
identified by a sequence of numbers, e.g.
   .1.3.6.1.2.1.2.2.1.10.2
is the "Object IDentifier" (OID) for the number of bytes received on the
second network interface of a system. Nobody can remember these
number-ID's, so there are short-hand notations for them - e.g. 
   IF-MIB::ifInOctets.2
represent the same data item. From this, you may also note that if
I have a third network interface, I could get the bytes received from
that one with IF-MIB::ifInOctets.3 .

So you can think of the last "2" or "3" as an index into the table 
of network interfaces. But there's an important difference: The
index need not be 1,2,3... it can be 1,2,7,902,10293 - e.g. one of 
the SNMP datasets details the running processes, and here the index
is the process-ID.

To access the data, you can use the "snmpget" utility from Net-SNMP. 
For this, you must know the exact OID you want to query, e.g.
   $ snmpget -c public -v2c localhost IF-MIB::ifInOctets.2
retries the number of bytes received in interface 2 on "localhost",
using the community name (userid) "public", and SNMP version 2c as
the protocol.

snmpget is very picky about the OID's. E.g. if you didn't know what
interfaces exist on a host, you might think that you could just do
   $ snmpget -c public -v2c localhost IF-MIB::ifInOctets
without the interface number in the OID; but this doesn't work:
   IF-MIB::ifInOctets = No Such Instance currently exists at this OID

So what do you do when you don't know the exact OID's, e.g. to get the
proces info ? You use the "snmpwalk" utility - this uses the SNMP "get
NEXT" query to traverse all of the available OID's.

   $ snmpwalk -c public -v2c localhost interfaces
   IF-MIB::ifNumber.0 = INTEGER: 3
   IF-MIB::ifIndex.1 = INTEGER: 1
   IF-MIB::ifIndex.2 = INTEGER: 2
   IF-MIB::ifIndex.3 = INTEGER: 3
   IF-MIB::ifDescr.1 = STRING: lo
   IF-MIB::ifDescr.2 = STRING: eth0
   IF-MIB::ifDescr.3 = STRING: ra0
   <lots more snipped>
   IF-MIB::ifLastChange.3 = Timeticks: (0) 0:00:00.00
   IF-MIB::ifInOctets.1 = Counter32: 14391389
   IF-MIB::ifInOctets.2 = Counter32: 1040756809
   IF-MIB::ifInOctets.3 = Counter32: 0
   IF-MIB::ifInUcastPkts.1 = Counter32: 200369

So here you can see that my box has 3 network interfaces, with index
1, 2 and 3. Their description is "lo", "eth0" and "ra0" which are
the names I use when configuring them in Linux. And I can see the
various statistics about them, including the in-byte-counts we looked
at earlier.

How do you know what the different items mean ? For that, you'll
have to look in the "MIB" files - these are text files, but with
a specific syntax (there are actually "MIB compilers") which contain
a description of all of the data items. These are either standard MIB's
defined by the Internet standard groups (IANA et al), or they are
vendor-specific MIB's that hardware- or software-vendors produce to
enable monitoring of their products. Net-SNMP ships with some of the
standard MIB files, on my Linux box they are in /usr/share/snmp/mibs/ .
In IF-MIB.txt, we find the ifInOctets definition:

ifInOctets OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
	"The total number of octets received on the interface,
	including framing characters."
    ::= { ifEntry 10 }

One important thing to note here is that it's a 32-bit counter;
with 100mbit or Gbit interfaces, this means it can wrap around
very quickly! There is actually an extension to the IF-MIB 
definition with 64-bit counters to handle this problem, but not
all devices have implemented support for it.


So to get back to hobbit_snmpcollect, what happens when you 
have an entry in the config file like

    [localhost]                                                
	version=1                                                  
	community=public                                           
	mrtg=2 IF-MIB::ifInOctets.2 IF-MIB::ifOutOctets.2 Main IO  
	# ifmib=2 LAN                                              
	# ifmib=(eth0) LAN                                         
	# ifmib=[0:e:a6:ce:d6:85] LAN                              
	ifmib={leopg9.no-ip.org} LAN                               

The "mrtg=2 IF...." line causes hobbit_snmpcollect to fetch those
two OID's, and report them in under the "[Main IO]" heading. That
is what your output shows - ds1 is the ifInOctets.2 value, and ds2
is the ifOutOctets.2 value. This is intended for people who would
like to keep the data from their old MRTG setups - the RRD file
generated by this data should be compatible with those produced by MRTG
(if you're running MRTG in the way that uses RRD files instead of the
old MRTG text-based datalogs).

The "ifmib=(leo..." line causes Hobbit to try and fetch all of the
network statistics for an interface. Since it's in parenthesis, 
hobbit_snmpcollect will try to find an interface where the ifDescr
item has the value "leopg9.no-ip.org". There is no such interface,
which is why this doesn't produce any data. If you had used the real
name of the network interface, it should work.


Regards,
Henrik