Мониторинг VPN-ноды: какие метрики снимать и как их читать
Мониторинг VPN-сервера — это не один график загрузки: качество складывается из полосы канала, железа ноды и связности с Россией, и «тормозит» звучит одинаково во всех трёх случаях.
Здесь разобрано, какие метрики снимать на каждом участке, каким прибором и как по симптому отличить зажатый хостером канал от упора в процессор и от плохого маршрута. Все числа — замеры с нашей боевой сети: 46 активных серверов, август 2026.
Имена машин в примерах условные («сервер А», «Сервер 1») — техника от этого не меняется.
Путь пакета от телефона до сайта — это четыре независимых участка. Сломаться может любой, а человек скажет одну и ту же фразу.
Дальше по одной главе на участок: канал сервера, железо ноды, связность с Россией. Каждая отвечает на два вопроса — что именно ломается и по какому признаку мы это видим, не спрашивая человека.
1. Канал сервера: как понять, что хостер зажал полосу
У сервера есть сетевой интерфейс, и нас в нём интересуют две вещи: какая полоса реально доступна и сколько от неё осталось свободного.
В тарифе может быть написано «порт 10 Гбит/с». Это характеристика инфраструктуры, а не обещание вашей машине: VPS живут поверх общего аплинка и конкурируют за него. Поэтому важнее не заявленная цифра, а то, как хостер делит канал между клиентами. Вариантов ровно три, и каждый чувствуется по-своему.
1.1 Никак не делит
Хостер не ограничивает никого. Одна шумная VPS способна выесть общий аплинк, и вашей машине достаётся то, что осталось.
Это худший вариант не по средней скорости, а по предсказуемости: соседи меняются, нагрузка меняется, и одна и та же нода в понедельник даёт 400 Мбит/с, а в пятницу вечером — 40. Проявляется всем сразу: падает скорость, растут задержки и джиттер, начинаются потери.
1.2 Шейпинг — очередь
Шейпер ограничивает скорость очередью: лишний трафик не выбрасывается, а ждёт своей очереди на отправку.
Пока очередь короткая, всё хорошо. Как только она набивается — каждый пакет проводит в ней время, и это время добавляется к задержке. Именно это человек называет «видео буферится, хотя скорость нормальная».
1.3 Полисинг — ножницы
Полисер очередь не держит: превысил лимит — пакет выброшен.
При одинаковом ограничении симптомы разные, и по ним же эти два механизма и различаются.
Ограничители наших хостеров оказались полисерами с разрешённым всплеском, и они не дают ни очереди, ни потерь. Замер 28.08 на зажатом сервере А: потери из России ровно 0.0 шесть часов подряд, задержка ровные 50.4–51.5 мс, ретрансмиты 1.8–2.6% — ниже, чем у здорового сервера В (1.5–4.1%).
Полисер режет только то, что выше лимита, а пробы шлют мелкие пакеты и под планку не попадают. Искать такое ограничение по потерям и по пингу бесполезно на любой стороне.
1.4 Почему пробы не видят потолок
У нас две активные пробы канала: одна живёт на самой ноде (качает 8 МБ в 4 потока, эскалирует до 16, дедлайн 12 секунд), вторая приходит из Петербурга. Обе качают около секунды — и обе попадают внутрь всплеска.
Это не гипотеза: 28.08 на сервере А собственная проба ноды за сутки читала то 100, то 2552 Мбит/с, проба из России — 153.8, а прямая закачка 100 МБ через её туннель прошла за 3.1 секунды (269 Мбит/с) — в тот самый момент, когда людям доставалось 0.3 Мбит/с на человека.
Ни одна короткая проба не увидит полисер с ведром. Единственный надёжный прибор здесь — счётчики самой машины на длинном окне. Пробы отвечают на «проходит ли трафик» и «насколько плох путь», но не на «сколько достанется человеку».
1.5 Проба меряет пол, а не потолок
Второе свойство пробы, о котором легко забыть: она занимает канал на 12 секунд и пишет, сколько получилось. Это нижняя граница полосы, а не верхняя. Причин занизить у неё много: свои же люди на ноде делят канал (там стоит CAKE), плечо до мишени длинное, TCP-окно не разгоняется.
Ровно на этом мы однажды чуть не пошли к хостеру с претензией, которую он отбивает своим же графиком.
| Нода | Проба (12 с) | Наблюдённый пик за 24 ч | Во сколько раз |
|---|---|---|---|
| Сервер 1 | 19 Мбит/с | 225 | 11.7× |
| Сервер 2 | 20 | 116 | 5.9× |
| Сервер 3 | 20 | 104 | 5.2× |
| Сервер 4 | 42 | 45 | 1.1× |
| Сервер 5 | 47 | 49 | 1.0× |
Разрыв чистый: либо отношение около единицы — машина правда упёрта, либо оно 4–12 — упёрта средняя скорость, а порт свободен. Отсюда порог отношения — 3, и отсюда же два разных вердикта в карточке: «порт срезан у хостера» и «зажата средняя скорость, порт свободен». Второй прямо запрещает писать хостеру «вы срезали нам канал» — он покажет график всплесков и будет прав.
Метрика пробы лежит в textfile-коллекторе и переживает остановку таймера. 27.08 выяснилось, что у серверов В и Г таймер был выключен девять с половиной суток, а карточка всё это время показывала замороженный вердикт «приём срезан до 20 Мбит/с». После включения таймера: сервер Г — 1215 Мбит/с, сервер В — 493, барьера нет ни у одной.
Отсюда порог свежести — 3 часа и правило: старый замер — не факт, а воспоминание.
1.6 Как мы всё-таки ловим ограничение
Раз пробам верить нельзя, признак строится на собственном трафике машины. Ограничитель рисует линию; живой спрос линию не рисует никогда. Дальше — четыре независимых условия, и полкой считается только то, что прошло по всем.
Признак первый — «ровный час». Смотрим, насколько медиана трафика за час близка к его же q90. У машины на потолке трафик почти всё время у одного и того же значения — 0.85–0.98. У машины со свободным каналом и живым спросом — 0.07–0.41.
Есть и второй вариант той же мысли — насколько кривая прижата к собственному максимуму часа (q90 ÷ пик). Он нужен машинам с рваным спросом, которые всё равно регулярно упираются в один и тот же потолок: у сервера Б это стабильные 0.997 против 0.48 у здорового сервера Д. Порог 0.97 жёсткий намеренно — на живых данных он добавил ровно две машины, и обе с настоящим упором.
Признак второй — «ровная линия короче часа». Час — грубое окно: одного всплеска внутри него хватает, чтобы поднять q90 и спрятать полку.
Поэтому рядом стоит второй прибор с другой величиной: разброс на 15-минутном окне (stddev ÷ avg). Здоровая машина на коротком окне тоже бывает ровной — десятки людей сглаживают друг друга, — а вот нулевого разброса живой спрос не даёт никогда. Замер 28.08 по 17 машинам за сутки: у восьми зажатых минимум 0.0000–0.0129, у девяти здоровых — не ниже 0.0609. Порог 0.02 стоит посреди этого разрыва, до здоровых втрое.
Признак третий — запас. Полка подозрительна только тогда, когда машина умеет быстрее. Доказательства два, и достаточно любого:
- за последнюю неделю машина уже проходила существенно больше — минимум в 2.5 раза;
- её собственная проба за сутки показывала существенно больше.
Одного источника мало, и это не перестраховка: у зажатой всю неделю машины истории нет по построению. У сервера А отношение «пик недели ÷ q90» было 1.7 — по истории она невиновна, — зато проба за сутки давала запас в 26 раз.
Признак четвёртый — люди. Пустая нода тоже «стоит ровно» — на нуле. Поэтому нужен и трафик от 10 Мбит/с, и живой онлайн.
Онлайн берётся со счётчика на самой ноде, а часть машин устроена так, что клиентский трафик идёт мимо него: на двух таких машинах онлайн равен 2 при сотне мегабит реального трафика. Поэтому второй путь условия самоописателен: столько трафика при почти нулевом видимом онлайне не берётся из ниоткуда — значит люди есть, просто мы их не считаем. Тот же путь закрывает и упавший экспортёр.
1.7 Что это значит для человека
Мегабиты сами по себе ничего не говорят. Значение имеет полка, делённая на число людей — и она же переводится в единственный понятный ответ: что человек сможет посмотреть.
1.8 Кто зажал канал — сводка
Одного прибора не хватает ни в одну сторону. Проба на ноде меряет плечо «нода → наш фронт», проба из России — весь путь до клиента. По отдельности каждая цифра допускает оба объяснения, вместе они их разводят.
| Что видно | Вывод | Что делать |
|---|---|---|
| Барьер у пробы, всплесков нет | порт срезан у хостера | к хостеру, с цифрами |
| Барьер у пробы, всплески кратно выше | зажата средняя скорость, порт свободен | к хостеру бесполезно — менять тариф или площадку |
| Канал ноды широкий, а из России единицы | зажат путь в РФ (транзит или ТСПУ) | хостер не поможет, менять площадку |
| Из России быстро, а проба ноды кричит о барьере | врёт проба ноды | верить клиентскому пути |
| Полка по счётчикам + запас + люди | упор в потолок прямо сейчас | смотреть, сколько достаётся человеку |
⚠️ Протухшая или сорвавшаяся проба в этот вердикт не идёт вовсе — тогда честнее сказать «кто зажал, пока не разделить», чем назвать виноватого наугад.
2. Железо ноды: процессор, steal и почему число ядер обманывает
Канал может быть свободен, а качество всё равно плохим: у VPN-ноды упор чаще приходится не на сеть, а на процессор. Здесь — то, что нужно, чтобы правильно читать спецификацию при покупке и понимать, какие метрики железа вообще имеет смысл снимать.
Главное, что стоит запомнить: число ядер в тарифе почти ничего не обещает. Сервер с четырьмя ядрами старого Xeon и сервер с двумя ядрами свежего Ryzen — машины разного класса, и второй нередко везёт VPN лучше.
2.1 Ресторан: повара и заказы
2.2 Частота — это половина ответа
Производительность ядра упрощённо равна IPC × частота: сколько работы процессор делает за такт, помноженное на число тактов. Современное ядро на 3 ГГц спокойно обгоняет старое на 3.5 ГГц — просто потому, что за такт успевает больше.
И boost-частота из спецификации («до 5.7 ГГц») — не режим постоянной работы под нагрузкой, а верхняя отметка.
Для VPN к этому добавляется криптография: AES-NI и подобные инструкции ускоряют шифрование. Но и по ним нельзя выбирать вслепую — разные протоколы используют разные примитивы и нагружают процессор по-разному.
Худший процессор флота шифрует 2.5 ГБ/с одним потоком, то есть около 20 Гбит/с. Наш трафик на машину — сотни мегабит, на шифрование уходят доли процента ядра.
Крипто-проба всё равно стоит в приёмке, но читать её надо как «какого класса это железо», а не «сколько машина потянет»: с поведением в бою она коррелирует на −0.72, потому что меряет поколение ядра, а не наш профиль нагрузки.
2.3 vCPU — не гарантия ядра
У виртуальной машины есть отдельная беда: vCPU не означает выделенное физическое ядро. Соседи по хосту конкурируют за то же железо, и гипервизор может просто не дать вашей машине процессорное время.
Изнутри это не выглядит как нагрузка — своя работа просто идёт медленнее.
Отсюда и правило: на приёмке и в мониторинге смотрим не на красивое число vCPU в тарифе, а на цепочку
класс ядра → скорость одного ядра → сколько ядер → криптоинструкции → steal → фактическая пропускная способность под нашей нагрузкой.
14.08 один из серверов при занятости 76–83% дала джиттер p95 854 мс против фона флота 79–90 мс. Поэтому «CPU в норме» заканчивается примерно на 75–80%, а не на сотне: в карточке ноды пороги 70 и 90.
И запомнить стоит вот что: рекорд флота за неделю — 678 Мбит/с, то есть 7% гигабитного порта. Упирается почти всегда процессор, а не канал.
3. Связность с Россией: маршрут, задержка и потери
Это самая важная часть и одновременно самая невидимая: и канал, и процессор мы держим в руках, а путь от телефона до ноды — чужой почти целиком.
Сервер может стоять в Германии, иметь 10-гигабитный порт и свежий процессор — и при этом быть плохим сервером, потому что трафик из России добирается до него через три лишние страны.
3.1 Из чего состоит путь
Возьмём обычный случай: человек в мобильной сети, включён наш VPN, открывается сайт.
- Устройство → базовая станция. Радиоканал. Тут мы не видим ничего и повлиять не можем.
- Базовая станция → сеть оператора. Транспортная сеть: оптика, региональные узлы — площадки с маршрутизаторами и коммутаторами. Это не «один главный компьютер», решение о каждом пакете распределено между десятками устройств.
- Магистраль. Высокопроизводительная сеть между крупными узлами оператора. Обязательного правила «регион → Москва → заграница» не существует: путь определяется топологией и маршрутизацией конкретного оператора.
- Международный стык. Важно не путать его с магистралью: магистраль — это сама сеть, а стык — соединение сетей двух операторов. Физически чаще всего это просто два маршрутизатора разных компаний, соединённых оптикой в одном здании. На одной площадке таких стыков могут быть десятки.
- Зарубежные сети. После стыка трафик идёт по сетям одного, двух, трёх транзитных операторов — и только потом попадает в сеть хостера и на нашу ноду.
3.2 Дорогу знает не карта, а сосед
Ни одно устройство не хранит «весь интернет» в виде списка дорог. Между сетями разных операторов — автономными системами — маршруты раздаёт BGP: каждая сеть рассказывает соседям, какие адреса через неё достижимы, а сосед по своей политике выбирает, кому верить.
Поэтому перед тем, как принять сервер в работу, мы запускаем с него трассировку до нескольких независимых российских сетей — интересен не только итоговый пинг, но и через какие сети идёт путь.
3.3 Что именно меряем
Три величины, и ни одна не заменяет другие:
- RTT — задержка туда и обратно;
- Loss — доля потерянных пакетов;
- Jitter — насколько разъезжается задержка между соседними пакетами (берём
mdevуping: ядро считает его точнее, чем мы по отдельным замерам).
Средний пинг у них почти одинаковый. Разница — в ровности, и именно она чувствуется как «рывки» и «скорость скачет».
Целей несколько, потому что одна сеть может фильтровать ICMP или обрабатывать его по остаточному принципу: увидим потери там, где с каналом всё в порядке. Проблема считается настоящей, если воспроизводится на независимых сетях.
Контрольная точка одна на все серверы — иначе сравнение нечестное: одну машину мы мерили бы до Москвы, другую до Владивостока, и «лучше» означало бы только «ближе».
3.4 Низкий пинг не гарантирует ничего
Два разных способа получить прекрасный ping и неработающий VPN.
Первый — направление. Пакеты с сервера в Россию и из России на сервер идут разными путями и подчиняются разным политикам. Именно так выглядит блокировка ТСПУ: адрес пингуется, а TCP-соединение из России не устанавливается вовсе.
Второй — полоса. RTT 40 мс, потерь 0 одинаково честно описывает и сервер на 50 Мбит/с, и сервер на 2 Гбит/с. Для человека это разные серверы.
Поэтому связность у нас — это не одно число, а четыре ответа сразу: куда идёт маршрут → насколько он ровный → сколько по нему реально проходит → устанавливаются ли соединения из России.
3.5 Проверка снаружи: проба из Петербурга
Проверка с самой ноды отвечает на «как сервер видит Россию». Нам нужен обратный вопрос — «как Россия видит сервер», и он не выводится из первого.
Для этого на арендованной машине в Петербурге живёт наша проба. Она не пингует — она подключается через ноду как настоящий клиент и качает файл.
| Что делает | Как часто | Зачем |
|---|---|---|
| Подключение через ноду наружу (204 на gstatic) | 15 минут | проходит ли клиентский путь целиком |
| Закачка через туннель, 16 МБ | 1 час | сколько достаётся одному клиенту |
| ICMP 50 пакетов + 20 TCP-рукопожатий на :443 | 15 минут | задержка, джиттер, потери — двумя разными способами |
Трассировка mtr, 20 циклов | 3 часа | где на пути начинаются потери |
Несколько решений внутри пробы, каждое куплено ошибкой:
- У пробы своя служебная личность на каждой машине, а не чей-то живой аккаунт: цена вскрытия арендованной машины — отзыв одной личности, а не чужая подписка. Ключ на диск не кладётся, забирается каждый прогон и удаляется после.
- Имя личности намеренно не похоже на пользовательский идентификатор — иначе проба стала бы +1 человеком в статистике онлайна и в DAU.
- Замеры канала идут по одному и в порядке давности. Параллельно — проба делила бы наш собственный канал между нодами и объявила бы медленными сразу всех; при постоянном порядке хвост списка не мерился бы никогда.
- Если результат ниже 80 Мбит/с, включается 8 потоков тем же объёмом. Разрыв между одним потоком и восемью — почерк потерь на пути, а не общего потолка: у сервера Е один поток дал 0.3 Мбит/с, восемь — 2.8.
- В каждом прогоне снимается контроль — та же закачка без туннеля. Плохой контроль гасит все выводы о нодах: инструмент обязан уметь сказать «сегодня слепну я, а не флот».
Он мерился одним потоком до нашего же фронта и показывал 18.6 Мбит/с, тогда как машина в тот же момент качала 583 Мбит/с с внешнего CDN. Одиночный поток на длинном плече упирается в TCP-окно, а не в канал.
Теперь контроль — лучший из двух: несколько потоков до своего фронта и независимая внешняя мишень. Обе половины публикуются отдельно: 834 Мбит/с наружу против 181 до фронта — это не шум, это измерение нашего собственного плеча.
Порог «пользоваться нельзя» — 25 Мбит/с, и он не назначен, а взят из разрыва в данных: в первом же замере 13 машин легли в 0.9–24.5 Мбит/с, а следующая дала 89.7. Между ними пусто.
Мишень закачки — наш собственный фронт, которого клиентский трафик не проходит. Через одну и ту же ноду в один момент: до нашего фронта 2.5 Мбит/с, до внешнего CDN — 11.7. Искажение у каждой машины своё, поэтому сравнивать по нему ноды между собой нельзя.
Читать его надо как «проходит ли трафик и насколько плох путь», а не «быстро ли будет человеку». На второй вопрос отвечает полка из главы 1.
3.6 Задержка под нагрузкой — то, что человек зовёт «лагает»
Вхолостую задержка почти всегда прекрасная. Интересно другое: что с ней делается, пока канал занят. Если на пути стоит шейпер, очередь набивается именно в этот момент — плеер не успевает наполнить буфер и встаёт, хотя «пинг нормальный».
Поэтому проба пингует публичный адрес ноды во время закачки, а не отдельно.
Два условия, без которых это число врало бы:
- Короткая закачка не имеет права давать цифру. На быстрой ноде 16 МБ уходят за 0.7 секунды, пинг успевает отдать пару пакетов — и «прироста нет» означало бы не «очереди нет», а «мы её не создавали». Порог — 1.5 секунды под нагрузкой, ниже него мы честно пишем «мерили, но коротко», а не «всё хорошо».
- Пингуем публичный адрес, а не туннель. Очередь копится на исходящем интерфейсе там, где стоит ограничитель; внутри туннеля мы мерили бы заодно и работу самого VPN-ядра.
Что этот замер показал по флоту: прирост есть ровно у одной машины из 38. То есть наши хостеры ставят полисеры (роняют лишнее), а не шейперы (копят очередь), и человек страдает от нехватки полосы, а не от задержки.
3.7 Трассировка: где на пути начинаются потери
Трассировка отвечает на «где», а не на «сколько». И это не педантизм — это главная ловушка раздела.
Отсюда два правила, по которым читается таблица маршрута в карточке ноды:
- потеря считается настоящей только если держится до последнего транзита; «рассосавшиеся» гасим серым и объясняем прямо под таблицей;
- величину потерь даёт не трассировка, а отдельная 50-пакетная проба. Трассировка шлёт горстку пакетов на транзит: один потерянный из десяти читается как 10%, и первый же прогон так «нашёл» четыре теряющие ноды, которых на самом деле не было.
Молчащие транзиты (???) в «шумные» не записываются: они не теряют часть пакетов, они не отвечают вовсе — это настройка роутера, и говорить о ней надо иначе.
Средний маршрут до нашей ноды — 11 транзитов. Заодно оттуда видно длинное плечо: у одного из серверов это восьмой транзит, +38.9 мс — переход границы.
3.8 Симптом → причина → что делать
| Что видим | Скорее всего | Куда идти |
|---|---|---|
| Полка по счётчикам, запас есть, людей много | хостер зажал среднюю скорость | тариф или площадка; претензия «срезали порт» не сработает |
| Проба ноды в барьере, всплесков нет | порт срезан | к хостеру с цифрами |
| Канал ноды широкий, из России единицы Мбит/с | плохой путь в РФ | менять площадку, хостер ни при чём |
| Пинг ровный, потери нулевые, а видео стоит | полисер с ведром | смотреть полку по счётчикам, пробам не верить |
| Задержка растёт под нагрузкой | шейпер с очередью | к хостеру: это его очередь |
| ICMP идёт, TCP из России не идёт | блокировка адреса | менять адрес, чинить нечего |
| Джиттер 8+ мс при нормальном RTT | плохой транзит | смотреть трассировку, менять маршрут или площадку |
| CPU выше 75–80%, джиттер вырос | упор в процессор | разгружать ноду или менять железо |
| Steal 5%+ при нормальной своей загрузке | шумные соседи по гипервизору | переезд на другую машину хостера |
3.9 Правила, которые дороже любой из цифр
«Не мерили» — это не «всё хорошо». Молчащая проба, протухший замер, нода вне скрейпа обязаны выглядеть как прочерк, а не как зелёная галочка. Замороженный вердикт девять суток показывал «канал срезан» у машины, которая давала 1215 Мбит/с.
Ноль ≠ отсутствие метрики. У лежащей машины трафик приходит нулём, и датчик рисовал «канал свободен» на мёртвом сервере.
Один прибор не выносит вердикт. Любое обвинение — хостеру, транзиту, машине — строится на двух независимых источниках, которые сошлись.
Списки конкретных машин протухают за неделю. 18.08 «медленными» были одни ноды, 27.08 — уже другие, причём одна и та же машина успела показать и 20 Мбит/с, и 618. В разговор с хостером идёт свежий замер, а не таблица из документа.
Шпаргалка: чем мы на что смотрим
| Прибор | Где живёт | На какой вопрос отвечает | Чего НЕ умеет |
|---|---|---|---|
| Счётчики машины (Prometheus) | на каждой ноде | сколько реально прошло, есть ли полка | не видит клиентский путь |
| Проба полосы | на самой ноде, раз в 3 ч | пол пропускной способности до нашего фронта | не видит потолок и полисер с ведром |
| Клиентская проба из Петербурга | арендованная машина в СПб | проходит ли клиентский путь, задержка, потери, канал | мишень наша, число нельзя читать как «скорость у человека» |
Трассировка mtr | оттуда же, раз в 3 ч | где на пути начинаются потери | не даёт величину потерь |
| CPU, steal, PPS, память | node-exporter на ноде | упирается ли машина в железо | не объясняет, что происходит за её пределами |
| Проба доступности адреса из России | наша сторона | заблокирован ли адрес из России | не отвечает за скорость |
Последнее правило, которое стоит унести с собой: пороги и формулировки вердиктов должны жить в одном месте. Если карточка сервера считает «жёлтый» по одному числу, а тревога срабатывает по другому, они рано или поздно расскажут об одной машине разное — и доверие к обеим пропадёт быстрее, чем найдётся расхождение.
Частые вопросы
Какие метрики снимать с VPN-ноды в первую очередь? Четыре группы: трафик по интерфейсу (по каждому направлению отдельно), загрузка процессора вместе со steal, задержка и потери до целевого региона, и результат клиентской пробы — подключается ли через ноду настоящий клиент. Первые две снимает node-exporter, вторые две придётся мерить активно: изнутри машины они не видны.
Почему график скорости показывает 2 Гбит/с, а людям достаётся 20 Мбит/с? Потому что короткая проба попадает внутрь разрешённого всплеска. Полисер с ведром отдаёт первые мегабайты на полной скорости и режет среднюю — а замер на 8–16 МБ заканчивается раньше, чем ведро опустеет. Реальный потолок видно только по счётчикам самой машины на окне в час и больше.
Как отличить шейпинг от полисинга? По симптому: шейпер копит очередь, поэтому под нагрузкой растёт задержка, а потерь нет. Полисер выбрасывает лишнее — задержка остаётся ровной, зато появляются потери. Если не видно ни того, ни другого, а скорость всё равно упирается в круглое число — это полисер с разрешённым всплеском, и ловится он только длинным окном.
Достаточно ли пинга, чтобы понять, что с сервером всё в порядке? Нет. Пинг не покажет ни ширину канала, ни блокировку: адрес может отвечать на ICMP, а TCP-соединение из нужной страны не устанавливаться вовсе. Нужны отдельные проверки — по разным протоколам и обязательно снаружи, со стороны пользователя.
Что означает высокий steal и можно ли с ним что-то сделать? Steal — это время, которое виртуальная машина простояла в очереди за физическим процессором: соседи по гипервизору забрали такты. Изнутри это выглядит не как нагрузка, а как «всё стало медленнее». Своими силами не лечится — только переезд на другую машину хостера или на выделенное ядро.
Почему трассировка показывает 95% потерь в середине маршрута, а связь работает? Промежуточный маршрутизатор ограничивает темп собственных служебных ответов, транзитный трафик при этом идёт дальше без потерь. Настоящей потеря считается, только если держится до последнего транзита; величину потерь надо брать не из трассировки, а из отдельной пробы с достаточным числом пакетов.