Как стать автором
Обновить

Как сделать простые метрики для оценки полосы пропускания сети?

Уровень сложностиСредний
Время на прочтение3 мин
Количество просмотров4.5K

Почему это надо?

Часто для решения различных задач приходится пользоваться услугами облачных провайдеров для аренды 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/charts
helm 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: node
  1. scrape_interval задает для Prometheus, как часто проводить измерение. Слишком часто дергать speedtest тоже не стоит, так как измерение нагружает сеть и cpu.

  2. kubernetes_sd_configs нужны для того, чтобы Prometheus каждый раз измерял скорость для каждого пода, а не любого попавшегося.

  3. relabel_configs нужны для того, чтобы привязать к данным метку лейбл ноды, чтобы было удобнее в Grafana смотреть данные.

3. Метрики Grafana

Для запуска Grafana в kubernetes кластере я воспользовался данным helm-chart. После запуска графана, надо указать в нем Prometheus в качестве источника метрик.

Теперь в графане нужно добавить отображение метрик, которые уже собираются. Достаточно добавить панель со следующим содержанием.

speedtest_download_bytes{node="$node"}*8 // Для downlink скорости
-speedtest_upload_bytes{node="$node"}*8 // Для uplink скорости

Результат

Вот такие графики получились.

Провайдер А (сервер в Германии). Я ограничил на графиках отображение всего что выше 1Gb/s, чтобы маленькие значения на графиках лучше читались. На данном графике все досаточно хорошо. Можно сказать что на сервере почти всегда есть нужная скорость в 1Gb/s за исключением небольшой просадки в самом начале графика.
Провайдер А (сервер в Германии). Я ограничил на графиках отображение всего что выше 1Gb/s, чтобы маленькие значения на графиках лучше читались. На данном графике все досаточно хорошо. Можно сказать что на сервере почти всегда есть нужная скорость в 1Gb/s за исключением небольшой просадки в самом начале графика.
Провайдер А (сервер в Германии). Данный сервер имеет достаточно сильные проблемы с сетью. Минимальные значения скорости сети достигают 158 MB/s downlink и 114 MB/s uplink . Это уже может быть проблемой, когда ваш проект требователен стабильной и быстрой сети. Обратите внимение на то, что это тот же самый провайдер, что и на первой картинке. Конфигурация серверов тоже одинаковая.
Провайдер А (сервер в Германии). Данный сервер имеет достаточно сильные проблемы с сетью. Минимальные значения скорости сети достигают 158 MB/s downlink и 114 MB/s uplink . Это уже может быть проблемой, когда ваш проект требователен стабильной и быстрой сети. Обратите внимение на то, что это тот же самый провайдер, что и на первой картинке. Конфигурация серверов тоже одинаковая.
Провайдер B (сервер в США). У данного сервера все еще хуже.
Провайдер B (сервер в США). У данного сервера все еще хуже.

Вывод

Данные облачные провайдеры не подходят под мои цели. Я уже нахожусь в поисках серверов по доступным ценам с гарантированной полосой пропускания. Если вам нужна быстрая и стабильная сеть, подходите к выбору облачного провайдера более ответственно. К сожалению, в моем кейсе сервера GCP и Amazon мне не подходят по причине высоких цен на траффик. Поэтому приходится искать другие решения.

Теги:
Хабы:
Всего голосов 6: ↑6 и ↓0+8
Комментарии18

Публикации

Работа

DevOps инженер
36 вакансий

Ближайшие события