Комментарии 22
Но ведь если канал чем-то занят, то такой мониторинг покаже необъективно низкую скороть?
На мой взгляд - это деструктивный метод получения нужного знания - скорости канала. При измерении Iperf-ом выжирается полезная полоса и в момент измерения она недоступна для основной задачи - прокачки трафика. Я бы сделал мониторинг загрузки полосы и задержки на какой-нибудь стабильный ресурс, чтобы понимать процент потери пакетов и средний отклик.
Замер происходит быстро. Сотрудники на объекте даже не замечают, что он прошёл. Замер происходит всего раз в 4 часа. А для отслеживания потерь пакетов и времени отклика есть ping.
Ну и в целом описанная мною реализация мониторинга не претендует на идеальную:)
Тогда я перестал понимать зачем нужны эти замеры (раз в четыре часа они мало что показывают)...
На мой взгляд, проще сделать график по загрузке канала (uplink/downlink), второй график по среднему отклику (в ms) от нужного ресурса, а третий график по количеству потерянных пакетов от нужно ресурса. Все это можно сделать с 5-и минутным интервалом и это будет куда более показательным, чем раз в 4-е часа грузить канал мусорном трафиком.
Основная задача подобных(но только сертифицированных) систем это оптимизация расходов на каналы связи.
Т.е. система фиксирует различные нарушения SLA и помимо отправки этих данных провайдеру, так-же включает их в различные отчёты.
И в случае если компания закупает пару сотен различных каналов, то с одной стороны понемногу набираются претензии на существенные суммы, перекрывающие стоимость системы мониторинга, а с другой позволяют относительно быстро определять косяки провайдера, когда он вместо закупленного расширения ранее купленных каналов расширил другие каналы, или не расширил ничего, а может и расширил, но не на заявленные объёмы.
Согласен, что раз в 4 часа - слишком большой интервал. А вот полезность данной проверки в том, что можно отловить перегруз на маршруте от точки А к Б, например после перестроения у провайдера маршрута на не самый оптимальный. Это актуально для длинных маршрутов
Странный подход к мониторингу честно говоря. Как уже выше написали - для таких ситуаций обычно мониторят среднюю скорость исходящего/входящего трафика и ставят алерты на резкое падение в течение длительного времени. Мониторинг почти всегда должен быть non-intrusive.
Нет, если работает и решает задачу то слава богу, но подход странный.
А зачем крон использовать, если можно выполнять какой-то item и им запускать замер?
Понятно зачем такое, сам пытался реализовать нечто подобное, но столкнулся с тем, что jperf не может принимать конкурентный трафик по одному порту с разных узлов, нужно открывать несколько и как то это учитывать.
Можно прикрутить smokeping и наблюдать визуально за каналами интернета. Очень удобная вещь.
У Cisco есть IP SLA, у Huawei - NQA. На основе постоянных автоматизированных тестов можно мониторить задержку, джиттер, и потери, и далее по функционалу несколько вариантов, данные забирать по SNMP. Единственный минус - не всё оборудование это поддерживает.
Но, с минимальным занятием полосы (30-60 Кбит/с, в зависимости от настроек, можно и больше, и меньше) - вполне объективная картина, и мгновенная реакция на обрыв именно измеряемого канала, если до объекта есть резервные каналы.
Давайте рассмотрим ситуацию, когда провайдер вместо купленных 40 Мбит/с отдаёт 5 Мбит/с. Как с помощью описанного Вами инструмента это отследить?
Косвенно по потерям, например, хотя это и неточный тест. Обычно при покупке делается проверка канала тем же иперфом, и потом канал просто мониторится по трафику и по IP SLA. Если вдруг при превышении 5 Мбит/с появляются потери, то, очевидно, там проблемы, и начинается работа с провайдером по устранению. Это не единственный вариант решения данной задачи. Ваш вариант очень интересный, но я бы делал его, скажем, в 5 утра раз в сутки (это зависит от особенностей конкретной сети, и непринципиально). Такого рода проблемы с провайдером я редко вижу по падению скорости, а вот полные прерывания сервиса - регулярно, и тогда ip sla лучше подходит, там данный функционал зашит.
Спасибо за статью, попробую применить у себя с некоторыми "НО".
Вы замеряете скорость при помощи TCP, которое зависит от многих факторов: tcp windows size, buffer size, length of buffer, parallel TCP-streams и т.д. И при идеально работающем Интернете можно замерить скорость и в 10 Мб/с и в 100 Мб/с, поэтому может возникнуть ложный вывод, что в низкой скорости Интернета виноват провайдер.
Лучше замерять не скорость, а ширину канала при помощи UDP, указывая ключ bandwidth в размере 80-90% от договорной скорости Интернета. Данные тест покажет наиболее точно реальную пропускную способность. И по опыту общения с ТП, они принимают показания iperf по UDP и приступают к поиску проблем на своей стороне.
По договору какую услугу вам продают: VPN или Интернет? Если VPN, то провайдер гарантирует ширину канала, если Интернет, то гарантирует только доступ, но не кач-во канала.
Можете пояснить, что такое 'hostname' и откуда этот параметр берётся?
proxy = subprocess.Popen(['hostname'], stdout=subprocess.PIPE)
В скрипте iperf3_speed_testing.py ошибки. Объект нельзя преобразовать в строку
zbx_datacontainer.server_active = proxy.split('\n')[0] - не работает
zbx_datacontainer.server_active = proxy.decode('utf-8').rstrip('\n') - работает
Непонятен повторный запуск процесса, когда уже получили ошибку -
while stdout_value.find('error') != -1 and stdout_json['error'] == 'error - unable to receive results: Resource temporarily unavailable':
Мониторинг скорости интернет каналов в Zabbix