Comments 18
Ещё можно запустить iperf3 в режиме сервера на серваке и с локальной/нудной машины запустить iperf3 в режиме клиента.
Ни графаны ни Прометея , ни докеров - две стандартные линуксов утилиты.
Насколько я понял, в этом кейсе полоса пропускания клиента, может стать узким местом сети. То есть вы можете измерять свою полосу пропускания, а не сервера. Также встает вопрос, как хранить эти данные. Потому что метрики нужны также в виде истории. А хранить каким то кастомным образом данные от 20 серверов, которые к тому же могут часто перезагружатся и тд не очень удобно. Зачем заниматься этим, если есть возможность использовать готовые решения. Либо я просто вас не понял
На самом деле speedtest тоже не показателен на 100%, так как замер идёт до ближайшего тестового сервера. А вот результаты измерений с помощью iperf до указанного вами адреса будут наиболее показательны. Метрики можете так же в TSDB складывать, используя iperf exporter например.
Согласен. Результат speedtest может давать погрешности. Я думал о варианте iperf, но отказался от него, так как необходимо иметь хотябы один эталонный сервер, с которого будут проводиться замеры. А это дополнительные денежные затраты. Но в качестве альтернативы можно рассматривать.
Погрешность бывает уж очень большой, если вы просто хотите понять не налюбил ли вас провайдер, то возможно speedtest это ок, но для реального мониторинга сервисов в проде, я бы всё-таки iperf использовал. При этом держать под это отдельный сервер естественно не приходится.
У меня просто кейс, в котором ни один из серверов не имеет гарантированную полосу пропускания. Как в таком кейсе с помощью iperf получать данные, котоым можно доверять? Можно с разных серверов проводить замеры, потом как то аггрегировать эти данные и выяснять на котором из серверов просел bandwidth? В моем конкретном случае speedtest выдаст более точные результаты, так как я уже прикрепил результаты своих замеров. При использовании iperf на замеры будет накладываться эта зигзагообразная кривая. Если же у вас в кластере есть сервре, который с гарантией дает 1-2-3 гигабита, то с него можно проводить такие замеры, у меня же такого сервера в кластере нет
Я вам приведу реальный кейс. Вообще не про k8s. Есть 4 физических сервера, у них один внешний канал и общая внутренняя сеть. Прикрутили мониторинг speedtest, по нему всё шикарно, от 800 до 1000 мб/с. А вот когда поочерёдно делаю замеры с помощью iperf до разных серверов в разных ЦОД и даже странах, получаю по факту максимум 200-300 мб/с. Что имеем в итоге? Вроде как провайдер нас не налюбил, ведь speedtest показывает практически гигабит, а вот с кривыми маршрутами и узкими местами есть проблемы. Естественно после предоставления всех логов, маршруты провайдер перестроил и iperf тоже показывает теперь заявленные цифры. Возможно в вашем случае speedtest имба, но я им максимум скорость домашнего интернета замеряю с недавних пор).
Вообще странно слышать про то что speedtest может показывать большую скорость чем есть на самом деле, и мне даже немного сложно в такое проверить. Могу представить ситуацию, когда speedtest показывает меньше. И да, если надо тестить скорость соединения между двумя ЦОД тогда логично использовать iperf (speedtest том такое измерять странно). Когда же надо протестировать скорость выхода в интернет, мне кажется логичнее использовать speedtest. В связке с несколькими ip адресами speedtest. Так как в вашем кейсе, возможно просто конечные сервера имели ограниченную пропускную способность, а ваш ЦОД( с которого вы проводили замер) как раз имел скорость, которую показал speedtest.
Кстати, speedtest позволяет задать пул серверов, и тогда результат будет более точным
Данные выкатываете в лог файл.
Ваша визуализация для «нормальной» работы не нужна - вы же не будете целый день смотреть на панель.
Далее пишите скрипт который раз в день, парусит лог и отправляет вам е-mail если канал упал.
Меньше чего поддерживать/настраивать не говоря о том что работать будет 24x7 и 1000 лет.
А в вашей графине/докере и т.д. Завтра выкатят несовместимое обновление и все рухнет.
На днях оказалось что родной vagrant не работает с последнее версией VirtualBox- никогда такого не было и вот опять.
Плюс сколько ресурсов у вас отжирает ваш набор сервисов и сколько будет жрать один iperf3 с парой скриптов?
Графана и Прометеус стоят почти в каждом kubernetes кластере.
Не представляю какое обновление должны выкатить, чтобы нельзя было больше в графане показать набор точек на графике)))
Speedtest ничего почти не жрет, за исключением момента замера, в прочем как и iperf3.
Ваше решение предполагает
1) сделать кронджобу, которая запускает iperf
2) сделать кронджобу, которая парсит лог файл
3) поднять smtp сервер, для того чтобы слать емейлы. (или использовать готовый, но его надо интегрировать)
4) как то продумать логику замеров, для того чтобы при замере между сереров А и Б понять что проблема в сервере А (а не в сервере Б). То есть надо измерять с каждого сервера несколько других и потом аггрегивать эти данные. При этом ваше решение вообще не работает в кейсе 2 нод. Так как как не проводи замеры, никода не поймешь, на какой стороне проблема.
5) Сделать общее хранилище логов, чтобы еще одна кронджоба проходилась по всем замерам и аггрегировала данные, для того чтобы понять в каком именно сервере проблема.
Возможно я чего либо не понимаю, но мне ваше решение кажется гораздо более сложным. Хотя в нем есть плюсы, если правильно все сделать, то можно получить более точные данные.
И это все, вместо того чтобы сделать helm install и добавить дешборд в графане. Графана и Прометеус в кластере обычно уже есть. У меня во всяком случае были, задолго до того, как появился speedtest-exporter.
Только быть готовым что сам тест забьет полосу.
Проблема speedtest в том, что пул серверов доступен официально. И настроить получение красивых цифр с этого пула может любой довольно ленивый провайдер. И такие истории уже были. Это как в историях специальных "оптимизаций" драйверов видеокарт, которые задействовались при запуске определенных известных тестов быстродействия, для получения маркетинговой привлекательности.
А вот проход трафика из одного ЦОДа в соседний, в одном городе, легко может уйти через условный Гондурас, по желанию вышестоящих магистральщиков. Гондурас, в данном случае не метафора. При этом отчет speedtest будет предательски показывать что со всеми провайдерами внутри города вы обмениваетесь трафиком прямо вот за соседней стенкой.
Возможно я не очень хорошо понимаю сети. В моем представлении это работает так, что Клауд провайдер может настроить свою сеть до внешних провайдеров таким образом, каким желает. Но когда пакеты выходят за пределы сети провайдера, они уже живут своей собсвтенной жизнью. И он никак не может оказать влияние на то, как пойдут пакеты. За исключением того случая, когда Клауд провайдер имеет в распоряжении свои магистральные сети, или каким то образом договорился с другими провайдерами, чтобы настроили для него маршрутизацию. Иначе как клауд провайдер может настроить путь из точки А в точку Б, если сети, по которым пойдут пакеты, ему не принадлежат?
Позанудствую:
Там, где подпись у скриншота - 158 MB/s downlink - это 1.3Gb/s. Ошибочка
Как сделать простые метрики для оценки полосы пропускания сети?