В сетевых метриках VDS/VPS легко запутаться, потому что каких их только нет. В статье разберу ключевые, расскажу, как их читать, и посоветую 10 лучших утилит для мониторинга сети.
Основные сетевые метрики
Прежде чем перейти к практике, расскажу, какие вообще сетевые метрики существуют, и чем они отличаются. Если у вас уже есть эти познания, то, преисполнившись ими, можете сразу переходить ко второму разделу.
Интерфейсные метрики
Это низкоуровневые показатели виртуальной сетевой карты — количество переданных и полученных байтов/пакетов, пропускная способность (bandwidth), текущая скорость передачи (throughput), а также счётчики ошибок и аномалий (CRC-ошибки, dropped/overruns, коллизии и пр.). Сюда же относится максимальный размер кадра (MTU) и параметры дуплекса/скорости линка.
Все эти метрики показывают, насколько интерфейс загружен, и нет ли проблем на канальном уровне. Дальше в каждом подразделе я буду рассказывать, где их глянуть в Linux и WS, но, как вы понимаете, источники у каждого свои.
Где посмотреть в Linux: команда ip -s link (или устаревшая ifconfig). Также можно смотреть /proc/net/dev.
Где посмотреть в Windows Server: команда netstat -e. В PowerShell есть Get-NetAdapterStatistics, который выводит похожие данные по каждому адаптеру. Можно также использовать оснастку PerfMon (счётчики Network Interface).
Метрики протоколов TCP/IP
Тут все показатели работы стека протоколов. Например, количество активных соединений и их состояние, число повторных передач сегментов, указывающих на потери пакетов (TCP Retransmits), уровень потери пакетов (packet loss), задержка (latency) и скачки задержки (jitter). Также в эту группу можно включить статистику по UDP, ICMP и прочему — их можно увидеть через утилиты.
Где посмотреть в Linux: ss (выводит список соединений), ss -s (показывает суммарную статистику) или netstat -s.
Где посмотреть в Windows Server: netstat -s в CMD выводит. В PowerShell можно использовать Get-NetTCPConnection для списка TCP-соединений и Get-NetUDPEndpoint для UDP.
ARP и смежные показатели
ARP — самый важный протокол, предназначенный для определения MAC-адреса другого компьютера по известному IP. Сам по себе он не измеряется в числах, но состояние ARP-таблицы и количество ARP-запросов влияют на сеть.
Например, при проблемах с ARP (дубликате IP или переполнении ARP-кэша) соединения на локальной сети будут теряться. По метрикам это можно увидеть в приросте ARP timeouts — пакеты могут вообще не доходить до цели, хотя интерфейс исправен.
Где посмотреть в Linux: ARP-кэш через команду ip neigh show или arp -n. Здесь смотрим, есть ли incomplete-записи.
Где посмотреть в Windows Server: ARP-таблица через arp -a. В PowerShell — Get-NetNeighbor (аналогично ip neigh), который выводит IP-адреса соседей и соответствующие MAC (entry state).
Пропускная способность и нагрузка на канал
Максимально возможная скорость сетевого интерфейса (например, 100 Мбит/с или 1 Гбит/с) — это теория. В этом случае важно смотреть на текущее использование канала (throughput), где высокое значение, близкое к порогу интерфейса, означает, что канал забит полностью.
Где посмотреть в Linux: ip -s link или ifconfig показывают не только суммы байт и скорость линка, но и текущую загруженность по трафику. Также можно регулярно смотреть cat /proc/net/dev или netstat -e (текущие байты).
Где посмотреть в Windows Server: в командной строке netsh interface ipv4 show subinterfaces (или без ipv4). Через PerfMon можно открыть счётчики «Network Interface» и наблюдать трафик в битах/с.
Ошибки и пакеты с аномалиями
Сетевой интерфейс считает различные ошибки (они, конечно, редки на VDS, но знать их стоит):
CRC errors — битые фреймы, обычно из-за проблем на физическом уровне (это к провайдеру),
frame errors — неправильные кадровые форматы,
collisions — столкновения на полудуплекс-сетях,
overruns — переполнение буферов, когда система не успевает обработать входящие пакеты,
carrier errors — проблемы несущей, потери сигнала и т. д.
Например, Tx errors на интерфейсе могут указывать на несогласование дуплекса — классическая ситуация, когда один конец линка в Half Duplex, другой в Full Duplex.
Где посмотреть в Linux: ip -s link (либо ifconfig) показывает поля ошибок (errors), переполнений (overruns), коллизий (collisions) и пр. Если нужно подробностей, то dmesg может рассказать про сетевые предупреждения, а ethtool -S <iface> выдаёт счётчики по драйверу.
Где посмотреть в Windows Server: общее число ошибок через команду netstat -e. В PowerShell Get-NetAdapterStatistics тоже выводит счётчики Errors и Discarded. Аналогично можно использовать PerfMon (счётчики «Packets Received Errors» и «Packets Outbound Errors»).
Отброшенные пакеты
Отдельно выделю метрику dropped — число пакетов, отброшенных интерфейсом. Если drop-пакеты растут, а overruns равен нулю, то скорее всего, дело не в перегрузке канала, а в протокольных причинах (например, «лишние» VLAN кадры).
Где посмотреть в Linux: поля RX dropped (при приёме) и TX dropped (при передаче) в ip -s link или ifconfig.
Где посмотреть в Windows Server: прямой команды нет, но Get-NetAdapterStatistics покажет discarded пакетов. Также в PerfMon есть счётчики «Packets Received Discarded»/«Packets Outbound Discarded».
Потеря пакетов
Потеря пакетов — яркий симптом проблем на пути следования данных. Она может быть обусловлена переполнением буферов (тогда пакеты дропаются на маршрутизаторах), помехами в беспроводных сетях, перегрузкой канала или багами в сети.
Небольшой packet loss (например, 0.1%) приемлем. Но всё, что выше нескольких процентов, уже заметно нарушает работу (особенно UDP-трафика, стриминга, VoIP).
Где посмотреть в Linux: утилита ping (с ключом -c) выводит процент потерянных ответов. Для трассировки и статистики используйте mtr (если установлена) или traceroute.
Где посмотреть в Windows Server: процент утраченных пакетов покажет ping (с -n). А tracert — команда для трассировки маршрута — может лишь выявить обрыв на маршруте.
Задержка и джиттер
Тут самая важная метрика — время прохождения пакета до целевой точки и обратно (RTT). В локальных сетях задержка может быть менее 1 мс, тогда как внутри одного дата-центра достигать нескольких миллисекунд. В свою очередь, рост latency зачастую сигнализирует о загруженности канала или удалённости узла, а Jitter — разброс задержек — критичен для голосового и видеотрафика.
Где посмотреть в Linux: ping измеряет RTT (время туда-обратно) до цели. Для измерения джиттера можно смотреть разброс значений ping, а traceroute или tracepath показывают время на каждом шаге маршрута.
Где посмотреть в Windows Server: задержку также показывает ping, а tracert (аналог traceroute) показывает время до каждого промежуточного узла. Для анализа джиттера есть pathping -n, но обычно его оценивают, анализируя множество результатов пинга на интервале времени.
Как видите, сетевых метрик много, поэтому для полной картины стоит смотреть на них комплексно. Есть и ещё один важный момент — и в Linux, и в Windows на VDS вы имеете дело с vNIC. Некоторые низкоуровневые вещи (типа реальных коллизий) там отсутствуют, ведь на уровнях ниже гипервизора все пакеты мультиплексируются в одну физику. Ошибки CRC на виртуалке маловероятны (нет «настоящих» электрических сигналов), поэтому доверять стоит в первую очередь динамическим метрикам — объёмам, ошибкам и потерям.
Как читать показатели
Одно дело — знать названия счётчиков, другое — понимать, норма это или проблема. Поэтому на примерах поясню, как интерпретировать метрики.
На интерфейсе высокая нагрузка…
Если графики или ifconfig показывают, что ваш VDS стабильно выбивает сотни Мбит/с из доступного гигабита — канал близок к насыщению. В такие моменты задержки растут, а новые соединения устанавливаются медленнее.
В свою очередь, высокая исходящая нагрузка (Tx) может быть следствием бэкапов, раздачи контента или, не дай бог, компрометации сервера (спам, DDoS-ботнет). А высокая входящая (Rx) показывает, что ваш сервер либо усиленно закачивает данные, либо подвергается мощному входящему трафику (злоумышленник или просто пик популярности).
При длительных пиках >80% от канала стоит или оптимизировать софт, или задуматься о тарифе с большим каналом.
Есть ошибки интерфейса…
В идеале на интерфейсах не должно быть ошибок, и их появление говорит о том, что с передачей беды. Например, RX errors с растущим числом frame- или CRC-ошибок обычно указывают на проблемы приёма — тут либо страдает физическая линия, либо сбои на уровне виртуального свича.
Появились дропы и перерасход…
RX drops говорит о переполнении входной очереди — сервер не успевает обрабатывать сетевые прерывания. Часто (но не всегда) росту этой метрики сопутствует увеличение RX overruns, что точно подтверждает отброс пакетов из-за переполнения бэклога сетевого стека.
Есть повторная передача и потери пакетов…
Retransmissions на уровне TCP — один из главных индикаторов проблем на сети. TCP автоматически повторно отправляет сегменты, если не получил подтверждение (ACK) за определённое время.
Небольшое количество ретрансмитов нормально (сеть не идеальна), но их рост не приносит ничего хорошего. Из причин — перегрузка канала (вашего или на пути), потеря пакетов на маршруте, или, например, «дальние» сетевые проблемы (какой-нибудь троттлинг у провайдера). Картину может дополнить packet loss, измеренный той же метрикой ping.
Определить, где именно теряются пакеты, помогает traceroute/mtr. Увидев, на каком узле потери, можно понять, чей это сегмент (ваш сервер, коммутатор провайдера, магистральный узел и т. д.). В целом, если метрики говорят, что потери не локальны, значит, дело в инфраструктуре провайдера.
Выросло время отклика…
Рост среднего времени отклика до важных узлов (базы данных, API, пользователей) говорит или о перегрузке сети, или о маршруте «в обход» (например, трафик пошёл через более длинный путь).
Если CPU не под 100%, канал не забит, а latency всё равно скачет — велика вероятность, что проблема у провайдера. Помочь тут может только заявка, но сперва убедитесь, что на сервере не включилась, к примеру, агрессивная QoS, ограничивающая исходящий трафик.
MTU и фрагментация
Неправильно настроенный MTU также может привести к скрытым проблемам. Например, если туннель выставляет MTU меньше стандартных 1500, но об этом «не знают» узлы, возможна фрагментация или отброс пакетов.
Например, если при размере 1472 (что с учётом заголовков даёт 1500) пинг не проходит, а при 1464 проходит, значит где-то MTU = 1492 (типично для PPPoE-соединений). На VDS такая ситуация часто бывает, если внутри поднят туннель (ну вы поняли какой).
Мой топ утилит для мониторинга сети
В целом, правильная интерпретация метрик приходит с опытом. Но одна команда в поле не воин, потому поделюсь некоторыми проверенными инструментами:
iftop — консольная утилита (Linux) для мониторинга пропускной способности сети в реальном времени. Своего рода аналог top для сети, который показывает активные сетевые соединения и сколько трафика они генерируют. Удобно, что вывод разделён по парам хостов, можно быстро проверить, кто с кем общается и на какой скорости.
NetHogs — ещё один консольный монитор (Linux), но он группирует трафик по процессам. Очень удобен при отладке, когда неясно, кто выкачивает весь интернет.
vnStat — демон для сбора статистики трафика по интерфейсам. Он не показывает, кто именно генерил трафик, но хранит суммарные данные по дням/неделям/месяцам. Отлично подходит, чтобы узнать, сколько трафика ушло за месяц, или посмотреть суточные паттерны нагрузки.
tcpdump — консольный сниффер, позволяет записать трафик в файл или быстро его фильтровать. С его помощью можно увидеть, какие именно пакеты теряются, на каком этапе сессии идут сбои.
Wireshark — GUI-приложение для подробнейшего разбора захваченного трафика, с декодированием протоколов. Может подсветить TCP Retransmissions (он даже маркирует их отдельным цветом в списке пакетов) и указать, какой RTT, окно и флаги у сегментов.
Netdata — агент, который устанавливается на сервер и сразу начинает собирать сотни метрик. Он имеет встроенный веб-интерфейс, на котором можно поглядеть красочные графики всех показателей в реальном времени.
Prometheus + Grafana — боевая связка для постоянного мониторинга множества серверов. Prometheus собирает метрики через специальные агенты, а Grafana уже отображает эти данные на дашбордах.
ntopng — продвинутый сетевой монитор с веб-интерфейсом, фокусирующийся именно на анализе трафика. Умеет «разбирать» трафик вплоть до протоколов приложений, показывает, какие IP и порты наиболее активны и строит графики по хостам.
MTR (My Traceroute) — консольный гибрид, заточенный на постоянное измерение потерь и задержек на каждом узле маршрута.
iperf3 — консольная утилита для тестирования пропускной способности сети между двумя узлами. В отличие от wget или speedtest-cli (где скорость может упереться в медленный диск или CPU), генерирует трафик прямо в оперативной памяти. Грубо говоря, позволяет провести «чистый» тест сети между двумя узлами.
И хоть это не отдельный инструмент, я всё равно упомяну довольно старый приём «netstat/ss + группировка». Он нужен, чтобы отсортировать соединения по числу коннектов или состоянию. Например, команда ss -tp | grep ESTAB | awk '{print $7}' | sort | uniq -c | sort -nr покажет распределение TCP-соединений по процессам.
Конечно, есть ещё десятки утилит для визуализации трафика в консоли, замеров скорости и мониторинга задержек... Но перечисленные — мой личный топ в работе с VPS.
В комментариях делитесь вашими лайфхаками и утилитами по анализу сетевых метрик и пишите, какие ещё гайды и подборки будут полезны для вас.
© 2026 ООО «МТ ФИНАНС»
