Чего ждёт поддержка и почему скриншот ping не работает
Сотрудник поддержки получает десятки обращений вида «плохой интернет». Полезным для него оказывается то, что можно проверить: точное время, маршрут, число потерянных пакетов и узел, на котором начинаются проблемы. Отчёт mtr содержит эти данные в компактном виде, а значит, обращение с ним обрабатывается быстрее, чем описание словами.
Отчёт не обещает решения: провайдер вправе сказать, что узел ограничивает служебные запросы. Поэтому и нужно собрать данные так, чтобы отличить настоящую проблему от ложной. Как читать столбцы, объясняется на странице про диагностику маршрута командой mtr.
Готовьте отчёт, пока проблема проявляется: тест в момент, когда всё работает, ничего не докажет.
Полезно также подготовить сравнительный отчёт до узла в той же сети, что и провайдер (например, до его сайта или адреса шлюза, если он известен). Если между двумя отчётами есть чёткая разница, у сотрудника появляется основа для локализации: он сразу видит, что проблема возникает на отдельном направлении, а не во всей сети.
Команда и её ключи
Основная команда: mtr -r -w -n -c 100 example.com. Для записи в файл добавьте перенаправление: mtr -r -w -n -c 100 example.com > mtr-report.txt. В macOS и на некоторых системах потребуется sudo.
| Ключ | Назначение в отчёте |
|---|---|
| -r | Режим отчёта: без интерактивного экрана, итог печатается один раз |
| -w | Широкий формат, имена узлов не обрезаются |
| -n | Только числовые адреса, без запросов имён |
| -c 100 | Сто циклов, что даёт достаточно данных |
| -b | Показать и имя, и адрес узла |
| -T -P 443 | Режим TCP на порт 443, если ICMP фильтруется |
Сто циклов по умолчанию занимают примерно сто секунд, так как отправляется по одному запросу в секунду. Если проблема кратковременная, увеличьте число циклов до нескольких сотен и запускайте в проблемное время. Некоторые версии mtr имеют ещё ключ -z для вывода номеров автономных систем, но он есть не везде, поэтому сверьтесь с справкой своей версии командой mtr --help.
Перед запуском проверьте, что у вас установлена актуальная версия mtr и что вы выполняете команду от нужного пользователя. Если вывод пустой или команда сообщает об отказе, причина, как правило, в правах доступа, а не в сети.
Что нужно приложить к обращению
Сам отчёт лишь часть картины. Добавьте описание условий, чтобы его можно было интерпретировать.
- Дата и время запуска, с часовым поясом. Если проблема периодическая, укажите время, когда она проявлялась.
- Способ подключения: проводное или Wi-Fi. Лучше проводное, иначе поддержка спишет потери на беспроводной канал.
- Целевой адрес и причина выбора: узел, который плохо работает у вас, и для сравнения контрольный узел, который работает нормально.
- Отчёт в обе стороны, если возможно: с вашего компьютера к узлу и с другого места (например, с арендованного сервера) к вашему внешнему адресу. Так видно и обратный путь.
- Краткая формулировка проблемы: что не работает, с какого времени, как часто.
- Ваш внешний адрес, если поддержка его просит.
Не публикуйте отчёты в открытых местах: в них видны адреса вашей сети и провайдера. Передавайте их только в обращении к поддержке или доверенным специалистам.
Хорошая практика ещё и в том, чтобы сохранить отчёт в текстовом виде, а не скриншотом: текст легко вставить в письмо или форму обращения и проще прочитать. Если форма не принимает длинный текст, приложите файл целиком.
Как сформулировать вывод из отчёта
Поддержке нужно не только число потерь, но и вывод, который вы сделали сами. Сформулируйте его короткими предложениями по образцу, подставив свои данные.
Пример (пример, адреса из блока документации): «В отчёте mtr от 21:10 потери начинаются на узле 203.0.113.9 (четвёртый переход) и составляют около 30 процентов, сохраняются на узлах 5 и 6 вплоть до цели. Первые три перехода без потерь. Подключение по кабелю. Аналогичная проверка к другому узлу проходит без потерь».
Такой текст показывает, что вы отделили локальную сеть от внешней, проверили контрольный узел и указали конкретное место. Не нужно обвинять конкретное оборудование или делать выводы о причинах: это задача провайдера.
Если потери есть на промежуточном узле, а цель отвечает нормально, не прикладывайте этот отчёт как доказательство проблемы. Сначала убедитесь, что затронута именно цель, иначе обращение отклонят и время будет потеряно.
Если проблема возникает несколько раз в неделю, сохраняйте отчёты в разные дни и присылайте подборку. Повторяемость картины (потери на одном и том же узле в один и тот же час) для инженера весомее любого единичного результата.
Типичные ошибки при сборе отчёта
Большинство отказов поддержки связаны с одними и теми же огрехами.
- Тест выполнен через Wi-Fi в дальней комнате, и потери отнесены на счёт радиоканала. Подключитесь кабелем.
- В отчёте слишком мало циклов (10–20): статистика недостоверна.
- Нет отчёта в момент сбоя, только «хороший» запуск.
- Использован ICMP при том, что приложение работает по TCP. Сравните оба режима.
- В компьютере одновременно идёт загрузка больших файлов, и канал забит собственным трафиком. Остановите загрузки на время теста.
- Данные переданы без времени запуска.
Если после проверки видно, что первый же переход, ваш роутер, показывает потери, сначала разберитесь с ним: перезагрузите, проверьте кабель, обновите прошивку. Для длительного наблюдения запись обычного ping с метками времени, описанная на отдельной странице, дополнит отчёт mtr. Только собственные сети и узлы, на проверку которых у вас есть право, подходят для таких тестов.