MRTG: пропускная способность порта коммутатора

797
amazinghorse24

В настоящее время у меня работает MRTG в коробке Debian. В настоящее время он опрашивает коммутатор Netgear на скорости около 7 портов, а затем составляет их графики. В настоящее время он записывает только бит / сек. Я хотел бы настроить MRTG для записи и отображения общего объема данных, прошедших через порт, а не только его скорости.

Я немного новичок в MIBS и SNMP, поэтому мне нужна помощь. Это коммутатор Netgear GS748AT, и я не совсем уверен, где найти MIBS для него или какие MIBS мне нужны для выполнения моей задачи.

Любая помощь приветствуется!

0
бит в секунду - это, по сути, выход, а не скорость, а скорость - это задержка. Пропускная способность - это мера того, сколько данных может поместиться через канал определенного размера в течение определенного периода времени. Таким образом, 1 мегабит в секунду означает, что за одну секунду может пройти до 1 мегабита. Если вы отображаете график использования (бит в секунду), то общее количество битов за указанный вами период времени (скажем, 1 неделя) - это использование за эту неделю. Я не уверен, как конкретно, чтобы войти, что в MRTG, хотя. MaQleod 12 лет назад 0
Это может быть полезно: http://serverfault.com/questions/367677/mrtg-total-throughput-in-week-month MaQleod 12 лет назад 0

1 ответ на вопрос

0
Nevin Williams

I'm afraid MRTG is not designed or even capable of tracking a cumulative counter, in the manner you're suggesting. While it does query the absolute values of the port traffic which each poll, it uses the difference between the two values to calculate the bounded rate, which it graphs. Furthermore, since MRTG log files do not grow in size over time, they must decrease in accuracy: The absolute values it receives from its polling and the deltas it calculates begin to have their precision fall off; this would not provide you with an accurate accounting over time. Since most low-end consumer devices only implement SNMP V1.0, its counters are only 32-bits: they roll over after 65536^2 octets, or about 4.3 Gigabytes of data. This too is a source of problems. MRTG has code to help it maintain a reasonable delta between rollovers, and device/port resets, but it does not, and cannot keep an absolute count of all packets sent.

At any given time, snmpget can be used to poll the absolute numbers on an interface or group of interfaces. In the following example, I have determined (by perusing the output of an snmpwalk) that my dslmodem's WiFi interface is number 9, and so I can pull its current absolute stats in this way:

[mini-nevie:~] nevinwilliams% snmpget -c public -v1 192.168.2.1 .sysUpTimeInstance .ifLastChange.9 .ifInOctets.9 .ifOutOctets.9 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (187184300) 21 days, 15:57:23.00 IF-MIB::ifLastChange.9 = Timeticks: (2500757) 6:56:47.57 IF-MIB::ifInOctets.9 = Counter32: 824681152 IF-MIB::ifOutOctets.9 = Counter32: 317952735

Which tells me that (though I'm not sure if it's 21 days, or 7 hours; I think the former, as it's not used much) that my WiFi interface passed 1.1 gigabytes of data. (I have since rebooted my DSL modem)

Another way of seeing the absolute counters is with the command snmpstatus:

[mini-nevie:~] nevinwilliams% snmpstatus -c public 192.168.2.1 [UDP: [192.168.2.1]:161->[0.0.0.0]:0]=>[Siemens Subscriber Networks 6520-Series (E752)] Up: 0:25:25.00 Interfaces: 22, Recv/Trans packets: 16230/28039 | IP: 5530/1696 5 interfaces are down!

which, as you can see, provides a much more condensed format. However, such data simply does not graph well.

Похожие вопросы