[ale] iptraf / bandwidth monitoring

Robert Story rstory-l at revelstone.com
Tue Feb 14 09:57:15 EST 2006


On Wed, 01 Feb 2006 06:32:24 -0500 Christopher wrote:
CF> I loaded up net-snmp on both boxes.  On my desktop I loaded up mrtg and
CF> I now have MRTG monitoring those machines.  But this only gives me
CF> averages and allows me to see spikes.  It does not count totals.  Or at
CF> least I don't have it configured correctly.

You are correct, it doesn't count totals.

CF> The only idea I can see is to at 11:59 on 02-01 use snmpget to get the
CF> value of IP-MIB::ifInOctects.2 and  ifOutOctects.3.  Once you get that
CF> value then periodically get that value again and calculate the
CF> difference.  That will tell you your bandwidth usage for that period.
CF> Your script will have to be intelligent because I believe that is a
CF> 32bit value that can roll over and a reboot of your server will return
CF> that value to 0.  This is just an idea and I'm sure there is a better
CF> way.

A 32bit counter can wrap as fast as 5 minutes on a 100MB link. It's closer to
30 seconds for gigabit.

Depending on the version of net-snmp that you have, and how you (or your
distro) configured it at compile time, 64bit counters are available. Most
reasonably recent versions will also have the DISMAN Event MIB support
configured in, which will allow snmpd to monitor itself, and send traps.
snmptrapd can be configured to run scripts on receiving traps.

So, with a little work, you could probably configure net-snmp to monitor
itself for bandwidth spikes, and send a trap. The trap could go to the local
snmptrapd (or your home box, firewalls/static ip permitting) to fire a script.
A local script could use tcpdump to capture traffic for a minute or so, and
you could then analyze that script for ip/port data of the bandwidth hog.

Another, perhaps simpler, method, would be to use iptables accounting rules.
That's what the hosting provider I use has set up to give me an idea of
bandwidth usage. This only helps monitor traffic on known ports, though.



More information about the Ale mailing list