Какие команды Linux использовать для трассировки маршрута до сервиса и измерения задержек?

Что проверяют

Умеете ли вы сами разобраться, почему сервис отвечает медленно: сеть, DNS, TLS или само приложение. Для Python-разработчика это обычная ситуация, когда «тормозит» внешний API или база. Следом спрашивают, как читать звёздочки в traceroute и чем задержка сети отличается от времени ответа сервиса.

Как отвечать

Инструменты стоит разделить по уровням:

• ping: доступность хоста и RTT по ICMP. -c 20 задаёт число пакетов, в итоге видны min/avg/max и потери. ICMP часто закрыт, и молчание ещё не значит, что хост недоступен;
• traceroute: маршрут по хопам. В Linux по умолчанию шлёт UDP, -I переключает на ICMP, -T -p 443 на TCP к порту сервиса (нужен root), -n отключает обратный DNS и ускоряет вывод;
• tracepath: то же без root, заодно показывает MTU на пути;
• mtr: ping и traceroute вместе, статистика потерь и задержек по каждому хопу. Для отчёта mtr -rwc 100 host, для проверки через фаервол --tcp -P 443;
• curl -w: задержка уже на уровне приложения. Переменные time_namelookup, time_connect, time_appconnect, time_starttransfer, time_total разложат запрос на DNS, TCP, TLS, ожидание первого байта и общее время;
• dig: время ответа DNS (Query time), частая причина медленного первого запроса.

Запускать это нужно оттуда, где работает ваш код: из контейнера или пода, а не с ноутбука. В образах python:*-slim этих утилит нет, их берут из отладочного контейнера или временно ставят пакетами. Для уже открытых соединений ss -ti показывает RTT и ретрансмиты.

Где спотыкаются

Считают задержку ping временем ответа сервиса. ICMP не проходит TLS и не ждёт обработки на сервере, для этого нужен curl -w или замер в самом коде.

Видят звёздочки или потери на промежуточном хопе и делают вывод о проблеме в сети. Роутеры ограничивают ответы на ICMP, значимы только потери, которые доходят до последнего хопа.

Забывают про DNS: медленным оказывается не сервер, а резолвинг, и curl -w это сразу покажет.