Почему это надо?
Часто для решения различных задач приходится пользоваться услугами облачных провайдеров для аренды VPS(Virtual Private Server). Чаще всего, провайдеры дешевых VPS серверов никак не гарантируют полосу пропускания сети. Однако обычно это не вызывает каких-либо неудобств, особенно если ваш проект не сильно требователен к скорости интернета.
В моем случае для моего проекта важна широкая полоса пропускания. И мне важна высокая скорость сети на протяжении всего жизненного цикла сервера. На текущий момент я пользуюсь услугами двух провайдеров, не буду их называть (назовем их провайдер А и провайдер Б).
Когда я арендую новый сервер, то для проверки скорости сети, я удаленно захожу на сервер и делаю тест скорости сети с помощью командной утилиты speedtest. Я вижу большую скорость интеренета и думаю, что данная скорость будет большую часть времени. Однако после введения метрик по ширине полосы пропускания, я сильно удивился.
Метрики
Работать все будет следующим образом. Prometheus будет с какой-то периодичностью дергать speedtest-exporter для получения данных по скорости интернета и сохрянять эти данные. Grafana будет забирать данные из Prometheus и отображать их.
1. Установка speedtest-exporter
Мои VPS сервера находятся в Kubernetes кластере. У меня уже установлены в кластере Grafana и Prometheus. Для speedtest helm chart я взял за основу докер образ billimek/prometheus-speedtest-exporter. В моем github репозитории вы можете найти helm chart для деплоя speedtest-exporter.
Для установки helm chart можно выполнить эти команды. В helm chart я использовал Daemonset для того, чтобы поднялся экземпляр speedtest-exporter на каждой ноде кластера.
helm repo add tarmalonchik https://tarmalonchik.github.io/charts/chartshelm install mychart tarmalonchik/speedtest-prometheus
2. Конфигурация Prometheus
После того, как поды поднимутся, надо добавить конфиг в Prometheus. Для того чтобы он собирал метрики с новых подов.
Я использовал данный helm-chart для установки Prometheus в мой kubernetes кластер. Этот helm-chart идет вместе с node-exporter (полезная штука, которая собирает много полезных метрик).
Для того, чтобы Promethues начал запрашивать данные у speedtest-exporter, надо добавить данную джобу в values.yaml helm-chart Prometheus. Добавлять джобу надо в scrape_configs.
- job_name: 'speedtest'
metrics_path: /probe
params:
script: [ speedtest ]
static_configs:
- targets:
- speedtest-exporter.default.svc.cluster.local:9469
scrape_interval: 10m
scrape_timeout: 10m
kubernetes_sd_configs:
- role: pod
namespaces:
names:
- default
selectors:
- role: "pod"
label: "app.kubernetes.io/name=speedtest-exporter"
relabel_configs:
- source_labels: [ __meta_kubernetes_pod_node_name ]
action: replace
target_label: nodescrape_interval задает для Prometheus, как часто проводить измерение. Слишком часто дергать speedtest тоже не стоит, так как измерение нагружает сеть и cpu.
kubernetes_sd_configs нужны для того, чтобы Prometheus каждый раз измерял скорость для каждого пода, а не любого попавшегося.
relabel_configs нужны для того, чтобы привязать к данным метку лейбл ноды, чтобы было удобнее в Grafana смотреть данные.
3. Метрики Grafana
Для запуска Grafana в kubernetes кластере я воспользовался данным helm-chart. После запуска графана, надо указать в нем Prometheus в качестве источника метрик.
Теперь в графане нужно добавить отображение метрик, которые уже собираются. Достаточно добавить панель со следующим содержанием.
speedtest_download_bytes{node="$node"}*8 // Для downlink скорости
-speedtest_upload_bytes{node="$node"}*8 // Для uplink скорости
Результат
Вот такие графики получились.
Вывод
Данные облачные провайдеры не подходят под мои цели. Я уже нахожусь в поисках серверов по доступным ценам с гарантированной полосой пропускания. Если вам нужна быстрая и стабильная сеть, подходите к выбору облачного провайдера более ответсвенно. К сожалению, в моем кейсе сервера GCP и Amazon мне не подходят по причине высоких цен на траффик. Поэтому приходится искать другие решения.
Комментарии (17)
VenbergV
23.10.2024 17:53Проблема speedtest в том, что пул серверов доступен официально. И настроить получение красивых цифр с этого пула может любой довольно ленивый провайдер. И такие истории уже были. Это как в историях специальных "оптимизаций" драйверов видеокарт, которые задействовались при запуске определенных известных тестов быстродействия, для получения маркетинговой привлекательности.
А вот проход трафика из одного ЦОДа в соседний, в одном городе, легко может уйти через условный Гондурас, по желанию вышестоящих магистральщиков. Гондурас, в данном случае не метафора. При этом отчет speedtest будет предательски показывать что со всеми провайдерами внутри города вы обмениваетесь трафиком прямо вот за соседней стенкой.
tarmalonchik Автор
23.10.2024 17:53Возможно я не очень хорошо понимаю сети. В моем представлении это работает так, что Клауд провайдер может настроить свою сеть до внешних провайдеров таким образом, каким желает. Но когда пакеты выходят за пределы сети провайдера, они уже живут своей собсвтенной жизнью. И он никак не может оказать влияние на то, как пойдут пакеты. За исключением того случая, когда Клауд провайдер имеет в распоряжении свои магистральные сети, или каким то образом договорился с другими провайдерами, чтобы настроили для него маршрутизацию. Иначе как клауд провайдер может настроить путь из точки А в точку Б, если сети, по которым пойдут пакеты, ему не принадлежат?
VenbergV
23.10.2024 17:53В общем смысле вы все правильно понимаете. Но везде есть люди. Им свойственно ошибаться и договариваться между собой.
И если про вашу потребность гонять трафик между соседними ЦОДами они не знают, пока вы об этом не заявите, то про маркетинговую привлекательность speedtest они точно знают.
SlavikF
23.10.2024 17:53Позанудствую:
Там, где подпись у скриншота - 158 MB/s downlink - это 1.3Gb/s. Ошибочка
Kahelman
Ещё можно запустить iperf3 в режиме сервера на серваке и с локальной/нудной машины запустить iperf3 в режиме клиента.
Ни графаны ни Прометея , ни докеров - две стандартные линуксов утилиты.
tarmalonchik Автор
Насколько я понял, в этом кейсе полоса пропускания клиента, может стать узким местом сети. То есть вы можете измерять свою полосу пропускания, а не сервера. Также встает вопрос, как хранить эти данные. Потому что метрики нужны также в виде истории. А хранить каким то кастомным образом данные от 20 серверов, которые к тому же могут часто перезагружатся и тд не очень удобно. Зачем заниматься этим, если есть возможность использовать готовые решения. Либо я просто вас не понял
trabl
На самом деле speedtest тоже не показателен на 100%, так как замер идёт до ближайшего тестового сервера. А вот результаты измерений с помощью iperf до указанного вами адреса будут наиболее показательны. Метрики можете так же в TSDB складывать, используя iperf exporter например.
tarmalonchik Автор
Согласен. Результат speedtest может давать погрешности. Я думал о варианте iperf, но отказался от него, так как необходимо иметь хотябы один эталонный сервер, с которого будут проводиться замеры. А это дополнительные денежные затраты. Но в качестве альтернативы можно рассматривать.
trabl
Погрешность бывает уж очень большой, если вы просто хотите понять не налюбил ли вас провайдер, то возможно speedtest это ок, но для реального мониторинга сервисов в проде, я бы всё-таки iperf использовал. При этом держать под это отдельный сервер естественно не приходится.
tarmalonchik Автор
У меня просто кейс, в котором ни один из серверов не имеет гарантированную полосу пропускания. Как в таком кейсе с помощью iperf получать данные, котоым можно доверять? Можно с разных серверов проводить замеры, потом как то аггрегировать эти данные и выяснять на котором из серверов просел bandwidth? В моем конкретном случае speedtest выдаст более точные результаты, так как я уже прикрепил результаты своих замеров. При использовании iperf на замеры будет накладываться эта зигзагообразная кривая. Если же у вас в кластере есть сервре, который с гарантией дает 1-2-3 гигабита, то с него можно проводить такие замеры, у меня же такого сервера в кластере нет
trabl
Я вам приведу реальный кейс. Вообще не про k8s. Есть 4 физических сервера, у них один внешний канал и общая внутренняя сеть. Прикрутили мониторинг speedtest, по нему всё шикарно, от 800 до 1000 мб/с. А вот когда поочерёдно делаю замеры с помощью iperf до разных серверов в разных ЦОД и даже странах, получаю по факту максимум 200-300 мб/с. Что имеем в итоге? Вроде как провайдер нас не налюбил, ведь speedtest показывает практически гигабит, а вот с кривыми маршрутами и узкими местами есть проблемы. Естественно после предоставления всех логов, маршруты провайдер перестроил и iperf тоже показывает теперь заявленные цифры. Возможно в вашем случае speedtest имба, но я им максимум скорость домашнего интернета замеряю с недавних пор).
tarmalonchik Автор
Вообще странно слышать про то что speedtest может показывать большую скорость чем есть на самом деле, и мне даже немного сложно в такое проверить. Могу представить ситуацию, когда speedtest показывает меньше. И да, если надо тестить скорость соединения между двумя ЦОД тогда логично использовать iperf (speedtest том такое измерять странно). Когда же надо протестировать скорость выхода в интернет, мне кажется логичнее использовать speedtest. В связке с несколькими ip адресами speedtest. Так как в вашем кейсе, возможно просто конечные сервера имели ограниченную пропускную способность, а ваш ЦОД( с которого вы проводили замер) как раз имел скорость, которую показал speedtest.
tarmalonchik Автор
Кстати, speedtest позволяет задать пул серверов, и тогда результат будет более точным
Kahelman
Данные выкатываете в лог файл.
Ваша визуализация для «нормальной» работы не нужна - вы же не будете целый день смотреть на панель.
Далее пишите скрипт который раз в день, парусит лог и отправляет вам е-mail если канал упал.
Меньше чего поддерживать/настраивать не говоря о том что работать будет 24x7 и 1000 лет.
А в вашей графине/докере и т.д. Завтра выкатят несовместимое обновление и все рухнет.
На днях оказалось что родной vagrant не работает с последнее версией VirtualBox- никогда такого не было и вот опять.
Плюс сколько ресурсов у вас отжирает ваш набор сервисов и сколько будет жрать один iperf3 с парой скриптов?
tarmalonchik Автор
Графана и Прометеус стоят почти в каждом kubernetes кластере.
Не представляю какое обновление должны выкатить, чтобы нельзя было больше в графане показать набор точек на графике)))
Speedtest ничего почти не жрет, за исключением момента замера, в прочем как и iperf3.
Ваше решение предполагает
1) сделать кронджобу, которая запускает iperf
2) сделать кронджобу, которая парсит лог файл
3) поднять smtp сервер, для того чтобы слать емейлы. (или использовать готовый, но его надо интегрировать)
4) как то продумать логику замеров, для того чтобы при замере между сереров А и Б понять что проблема в сервере А (а не в сервере Б). То есть надо измерять с каждого сервера несколько других и потом аггрегивать эти данные. При этом ваше решение вообще не работает в кейсе 2 нод. Так как как не проводи замеры, никода не поймешь, на какой стороне проблема.
5) Сделать общее хранилище логов, чтобы еще одна кронджоба проходилась по всем замерам и аггрегировала данные, для того чтобы понять в каком именно сервере проблема.
Возможно я чего либо не понимаю, но мне ваше решение кажется гораздо более сложным. Хотя в нем есть плюсы, если правильно все сделать, то можно получить более точные данные.
И это все, вместо того чтобы сделать helm install и добавить дешборд в графане. Графана и Прометеус в кластере обычно уже есть. У меня во всяком случае были, задолго до того, как появился speedtest-exporter.
amario
Только быть готовым что сам тест забьет полосу.
tarmalonchik Автор
Справедливое замечание)