Утилита mtr в Linux: полный обзор команды для трассировки маршрута IP. Узнайте, что показывает трассировка маршрута до сервера, как использовать команду mtr для диагностики сети с примерами и разбором результатов.

Команды:

mtr (my traceroute - мой трассировщик) 

mtr -r (-report - отчет) -b (-both - оба) -c (-count - считать) 10 8.8.8.8

mtr -n (-numeric - числовой формат) 8.8.8.8

Следующая утилита в нашем наборе, это mtr

mtr (my traceroute - мой трассировщик)  и она является расширенной версией утилиты tracerout.

Что показывает mtr?

Давайте выполним трассировку пути до гугловского сервера через утилиту mtr

mtr 8.8.8.8

                                                        Packets               Pings
 Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                                         0.0%    90    0.4   0.8   0.2   3.4   0.6
 2. 192.168.88.1                                     0.0%    90    1.5   2.2   0.9  13.3   1.5
 3. 100.66.0.1                                       0.0%    90    5.7   2.8   1.7  18.2   1.8
 4. 178.34.130.56                                    0.0%    90    4.7   3.4   1.8  15.4   2.4
 5. (waiting for reply)
 6. (waiting for reply)
 7. 142.251.53.63                                    20.2%    89   38.6  39.4  37.9  42.7   1.0
 8. 192.178.241.66                                   28.1%    89   38.9  40.5  37.6  63.2   5.1
 9. 192.178.240.239                                  26.1%    89   45.0  46.4  43.8  79.9   5.6
10. 74.125.253.109                                    1.1%    89   63.8  52.7  49.7  70.6   3.8
11. 209.85.254.179                                    0.0%    89   51.5  52.5  51.2  62.0   1.6
12. (waiting for reply)
13. (waiting for reply)
14. (waiting for reply)
15. (waiting for reply)
16. (waiting for reply)
17. (waiting for reply)
18. dns.google                                      71.6%    89   52.5  52.1  48.9  55.3   1.4

По сути, мы видим аналогичный вывод утилиты traceroute, однако с определенными дополнительными данными, которые отображается в виде таблички.

Расшифровка таблицы результатов: ключевые метрики

И тут есть следующие параметры:

- **Host** — имя хоста или IP-адрес промежуточного узла (маршрутизатора, шлюза) на пути к целевому серверу. Например, `_gateway` или `192.168.88.1` — это локальные узлы, а `dns.google` — конечный хост.

Аналогичным образом, чтобы вместо имен, выводились IP адреса, добавим ключ -n

mtr -n (-numeric - числовой формат) 8.8.8.8

mtr -n 8.8.8.8

Кстати, давайте сразу настроим вывод таким образом, чтобы отображался и IP адрес и имя хоста, для этого добавим ключ -b

mtr -b (-both - оба) 8.8.8.8

mtr -b 8.8.8.8

Теперь, там, где это возможно, у нас отображаются DNS имена

Данная утилита объединяет в себе функции работы утилиты traceroute и ping. Она выводит результаты в аналогичной таблице, как и traceroute, однако тут добавляются дополнительные значения о результате отправки на каждый найденный узел ICMP пакета по аналогии работы утилиты ping.

- **Loss%** — процент потери пакетов на данном узле. Потери 0.0% означают, что все пакеты дошли до узла и получили ответ. Высокие потери указывают на проблемы: перегрузку канала, нестабильное соединение или фильтрацию трафика.

Как вы видите, на пути ближайшему к нам, потерь нет, либо они минимальны, это означает, что с нашей сетью все нормально. Если же мы видим, что большие потери на каком-то из первых устройств, за которые мы отвечаем, то необходимо провести более детальную диагностику конкретной железки.

Возможно, оборудование ведет себя не совсем адекватно. На моей практике, бывало, такое, что большие потери были связанны с плохим обжимом кабеля, либо неисправной работы порта на коммутаторе.

Кстати, с таким отчетом вы можете обратиться к провайдеру, если проблемы начинаются сразу после вашего оборудования. Как правило, сами технические специалисты провайдера запускают данную утилиту, чтобы локализовать проблему.

- **Snt** (Sent) — количество отправленных ICMP-пакетов на данный узел. Чем больше пакетов, тем точнее статистика.

- **Last** — время задержки (в миллисекундах) последнего отправленного пакета до данного узла. Показывает текущее состояние канала.

- **Avg** (Average) — среднее время задержки всех пакетов, отправленных на узел. Наиболее важный показатель для оценки общей производительности соединения.

- **Best** — наименьшее (лучшее) время задержки среди всех пакетов.

- **Wrst** (Worst) — наибольшее (худшее) время задержки.

- **StDev** (Standard Deviation) — стандартное отклонение задержки. Показывает, насколько сильно варьируется время отклика от минимального к максимальному значению.

Стандарты допустимого отклонения времени отклика.

0.0 – 1.0 мс — отлично, соединение очень стабильное. Задержки почти не изменяются. Такое значение характерно для локальных сетей, качественных проводных соединений и надёжных каналов.

1.1 – 3.0 мс — хорошо, небольшие колебания допустимы. Подходит для большинства задач, включая веб-серфинг и потоковое видео. Может наблюдаться на Wi-Fi или при умеренной нагрузке на сеть.

3.1 – 5.0 мс — удовлетворительно, но уже требует внимания. Возможны небольшие "подтормаживания" в VoIP или онлайн-играх. Среднее значение (Avg) может быть неточным — стоит смотреть на разницу между Best и Wrst.

5.1 – 10.0 мс и выше — плохо, указывает на серьёзную нестабильность: перегрузку канала, проблемы с маршрутизацией, неисправное оборудование или перегруженный узел. Критично для приложений, чувствительных к задержкам.

Режим отчетности: для автоматизации и детального анализа

Мы можем запустить утилиту в режиме отчета, т.е. мы не будем видеть в реальном времени процесс работы этой утилиты, однако, мы увидим финальный отчет.

Проще всего это сделать командой

mtr -r (-report - отчет) -b (-both - оба) -c (-count - считать) 10 8.8.8.8

mtr -rbc 10 8.8.8.8

Причем, при режиме отчета, обязательно нужно указывать количество пакетов, иначе программа не завершит свою работу, и вы не получите вывод статистики на экран.

Так же, удобно перенаправлять вывод статистики в файл.

mtr -rbc 10 8.8.8.8 > mtr_report.txt

Допустим, если мы добавим еще знак больше, тогда значения не будут перезаписываться, а будут добавляться. Таким образом, мы можем поставить данный скрипт в планировщик заданий, чтобы просматривать информацию о том, как, различные временные промежутки, себя вела сеть.

mtr -rbc 10 8.8.8.8 >> mtr_report.txt

Ну, а дальше уже все зависит от ваших задач, возможно вам нужно, анализировать стабильность работы сети в рабочее и ночное время и т.д.

Да, 10 пакетов маловато для получения наиболее актуальной картины, но 10 я привел в качестве примера, чтобы долго не ждать отчета, в боевых же условиях лучше указывать от 100, а то и 1000 пакетов.