Когда приложение начинает работать нестабильно, а причина не очевидна, первое подозрение часто падает на сеть. Но обычный
ping может показать, что узел доступен и задержка выглядит нормальной, хотя пользователи всё равно получают тайм-ауты.Проблема может быть не в доступности сервера, а в качестве сетевого пути: потерях пакетов, скачках latency, перегруженном участке маршрута или проблемах у провайдера.
Для таких случаев удобно использовать
mtr — инструмент, который объединяет возможности ping и traceroute и позволяет увидеть, где именно начинается деградация. Запуск:mtr api.example.com
MTR показывает маршрут до узла и статистику по каждому промежуточному хопу: задержку, количество отправленных пакетов и возможные потери ответов.
Для длительного тестирования удобно использовать:
mtr -rwbc 100 api.example.com
Параметры:
-r — вывести итоговый отчёт и завершить выполнение; -w — расширенный формат вывода; -b — показывать IP-адреса вместе с именами узлов; -c 100 — отправить 100 пакетов.Для больших маршрутов иногда удобнее отключить DNS-резолвинг:
mtr -n api.example.com
Сохранить результат для дальнейшего анализа:
mtr -rwbc 100 api.example.com > mtr-report.txt
Важный момент: потери на промежуточном узле не всегда означают реальную проблему. Многие маршрутизаторы ограничивают обработку ICMP или имеют низкий приоритет для таких ответов. Один из хопов может показывать высокий процент потерь, а конечный сервер при этом работать нормально.
Смотреть нужно не на один отдельный узел, а на общую картину: сохраняется ли проблема дальше по маршруту и влияет ли она на конечную точку.
Для проверки конкретного TCP-сервиса можно использовать:
mtr -T -P 443 api.example.com
В этом режиме MTR использует TCP SYN probes вместо ICMP, что ближе к проверке реального пути для сервисов вроде HTTPS, SSH или API. Примеры:
# HTTPS
mtr -T -P 443 api.example.com
# SSH
mtr -T -P 22 server.example.com
Но важно понимать: TCP MTR проверяет сетевую доступность и транспортный уровень. Он не покажет проблемы внутри TLS, HTTP или самого приложения. Полезно сравнивать разные направления:
mtr -T -P 443 server-a.example.com
mtr -T -P 443 server-b.example.com
Если один маршрут стабильный, а другой показывает рост задержки или потерю пакетов, причина может быть в конкретном направлении маршрутизации, провайдере или сетевом сегменте.
🔥
mtr полезен в ситуациях, когда сеть вроде работает, но есть плавающие тайм-ауты, скачки задержки или проблемы только с отдельными сервисами. Он помогает найти участок маршрута, где начинается деградация, но всегда требует анализа вместе с приложением и другими сетевыми метриками.➡️ DevOps Ready | #практика