Я могу изобразить интерфейс устройства с помощью инструментов SNMP, платформы, такие как Cacti, даже создают красивые графики, но они основаны на интервалах опроса (обычно каждые 5 минут).
Я могу использовать CLI;
r1>show int gi0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is BCM1250 Internal MAC, address is 0011.2233.4455 (bia 0011.2233.4455)
Description: link 1
MTU 1540 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 35/255, rxload 20/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/3208/72484 (size/max/drops/flushes); Total output drops: 1373910311
Queueing strategy: Class-based queueing
Output queue: 0/1000/12 (size/max total/drops)
5 minute input rate 79658000 bits/sec, 19312 packets/sec
5 minute output rate 140174000 bits/sec, 21984 packets/sec
Я вижу по 5-минутной выходной скорости, что я передаю 140 Мбит / с трафика, но это среднее значение за последние пять минут. Так что не сейчас и не лучше, чем Cacti и все такое.
Я мог ввести команду интерфейса load-interval 30 чтобы снизить частоту дискретизации до 30 секунд, после чего значения txload и rxload станут более точными.
Опять же, если мне нужно выяснить, какой канал сейчас исчерпан, мне трудно поверить, что, несмотря на все удивительные возможности маршрутизаторов и коммутаторов Cisco, они не могут сказать мне текущую скорость передачи / приема для интерфейса. , сейчас.
Я понимаю, что для достижения такой цифры может потребоваться период выборки, что не так с 1 секундой? Конечно, нагрузка на ЦП не так велика, если просто подсчитать количество пакетов, проходящих каждую секунду, и их размер?
Возможно, кто-то разработал свой собственный способ решения этой проблемы? Я вижу других, которых преследует та же загадка?
ОБНОВИТЬ: Я должен был дать лучший контекст для этого, поэтому я попробую сделать это сейчас.
Обычно мне нужно знать пропускную способность интерфейса прямо сейчас, когда звонит клиент, у которого есть порт 100 Мбит / с, и говорит: «Эй, я загружаю X с вашего зеркального сервера, но он передает только со скоростью 20 Мбит / с». Я хочу видеть пропускную способность их коммутатора прямо сейчас, пока они разговаривают со мной по телефону, чтобы подтвердить это (нетехнические клиенты, по моему опыту, часто сообщают неверные значения).
Итак, в этом сценарии я могу подтвердить, получает ли порт клиента уже 100 Мбит / с, поэтому они получают только 20 Мбит / с, потому что их порт загружен, или они даже передают со скоростью, подобной заявленной (будь то выше или ниже) . Кроме того, далее я хочу увидеть пропускную способность маршрутизатора, на котором установлен коммутатор, для всех этих клиентов, это еще одно потенциальное узкое место. Кроме того, я могу проверить порт коммутатора зеркального сервера во время передачи.
Я не хочу отвечать клиенту словами «Хорошо, убедитесь, что вы продолжаете загрузку еще 5 минут, чтобы я мог подождать, пока $ NMS_OF_CHOICE опросит интерфейсы», что не является приемлемым ответом в глазах клиентов. Я могу привести еще много сценариев, но, по сути, жалобы клиентов - это главный приоритет :)
Я не разработчик коммутаторов, поэтому не могу сказать, сколько будет стоить мониторинг на этой частоте.
Что я могу сказать, так это то, что я столкнулся с ситуацией где даже секунды не всегда достаточно потому что вы можете переполнять буферы за периоды короче секунды. Поэтому, если вы хотите узнать, исчерпана ли ссылка, я рекомендую посмотреть отброшенные пакеты. (Вы также можете отслеживать это через SNMP). Если вы отбрасываете пакеты (несколько из них - нормально, но много - нехорошо), то вам требуется больше, чем интерфейс может обработать. Это также может произойти на ваших серверах еще до того, как они переключатся. Точная скорость отброшенных пакетов обычно не важна, но если они будут увеличиваться каждый show interface вы, вероятно, в плохом месте.
Что касается Cacti, это не ограничение коммутатора или SNMP. SNMP записывает отправленные и полученные биты как увеличивающийся счетчик, поэтому, если вы опрашиваете каждую секунду, вы получите посекундное разрешение. Это работает так: метка времени каждой выборки берется вместе с текущим счетчиком. Затем он берет разницу и выражает ее в единицах «в секунду», но на самом деле это скорость за 5 минут, преобразованная или выраженная в секундах.
Если вы попытаетесь опрашивать SNMP каждую секунду, вам лучше следить за своим процессором.
Ваш интерфейс передает и принимает на полной скорости. На самом деле он ничего не передает со скоростью 140 Мбит / с, это просто среднее значение за интервал. Использование трафика в реальном времени было бы бесполезно для вас как человека-читателя, потому что это было бы постоянное переключение между отправкой / получением со 100% и 0%. Если вас беспокоит, насколько быстро вы сможете определить проблему с сетью, я бы посоветовал то, что сказал @ Kyle-Brandt выше. Отброшенные пакеты - лучший индикатор чрезмерно загруженного канала.
Монитор интерфейса реального времени SolarWinds, часть Набор инструментов сетевого инженера может опрашивать интерфейсы через SNMP каждые 5 секунд.
Опрос сетевых интерфейсов через SNMP каждые 5 секунд - это не то, что администраторы должны делать часто как часть решения для постоянного мониторинга. Однако для мониторинга на временной основе, есть несколько случаев, когда может быть полезен интервал опроса менее 60 секунд.
Понимание интервалов опроса - по мере их увеличения и уменьшения - имеет первостепенное значение для возможности интерпретировать данные, поступающие из инструментов.
Как вымышленный (но концепт видели много раз) пример, интерфейс, который регистрирует Использование 90% с интервалом в 5 секунд может не привести к проблемам, воспринимаемым конечным пользователем, однако тот же интерфейс на 50% загрузка с интервалом 60 секунд может фактически привести к проблемам, воспринимаемым конечным пользователем.
Большинство администраторов ошибочно полагают, что использование 50% за 60-секундный интервал каким-то образом «меньше» 90% -ного использования за 5-секундный интервал. Это не «меньше чем» - это не «больше чем». Короткий ответ заключается в том, что показатели использования нельзя сравнивать, как если бы они были эквивалентными цифрами, потому что интервалы разные.
Погрузиться поглубже - и покажите, как крайности могут повлиять на математику - интерфейс может работать со 100% -ным использованием в течение полных 30 секунд - затем замолчать на 30 секунд - и использование в 60-секундном интервале все равно будет 50%. В течение 30 секунд 100% использования приложения конечного пользователя испытали достаточную потерю пакетов и / или задержку до тайм-аута / прерывания отображения сообщения.
Сравните это с 90% загрузкой на 5-секундном интервале. Случай, когда даже если интерфейс был загружен на 100% в течение 4,5 секунд, а затем молчал в течение 0,5 секунды, что приводило к загрузке на 90% за 5-секундный интервал, потери пакетов и / или задержки может быть недостаточно, чтобы вызвать конечного пользователя пока не реагирует.
Приведенные выше примеры являются полностью вымышленными, однако концепция неоднократно наблюдалась. Убедительная оценка избыточной подписки / чрезмерного использования интерфейса зависит от знания инструментов мониторинга, понимания интервалов мониторинга / опроса и интерпретации выходных данных инструментов мониторинга / опроса и поведения используемых приложений.
Я написал сценарий ожидания для опроса байтов, отправляемых / получаемых для меня каждую секунду из вывода команды "show int xxx". Разница между каждой секундой - это трафик через интерфейс.
Базовый сценарий находится здесь: http://tinyurl.com/c2sx2fc
Это был мой первый сценарий ожидания, поэтому мой поток переполнения стека здесь :) http://tinyurl.com/82gtk3e
Я добавлю некоторые функции, такие как сбросы и отбрасывания, и сделаю два сценария: один для входящего трафика, а второй - для исходящего.