Зачем журналу нужна метка времени
Периодические обрывы трудно поймать вручную: вы замечаете сбой, открываете окно ping, и к этому моменту всё уже восстановилось. Гораздо надёжнее оставить проверку работать на несколько часов и потом прочитать журнал. Но обычное перенаправление вывода в файл сохраняет только сами строки ответов без времени, и по такому журналу нельзя понять, когда именно случилась пауза.
Ключ -t в Windows делает ping непрерывным, а вот метку времени команда не добавляет: этого ключа в ping.exe нет. Поэтому время дописывают отдельным шагом, пропуская каждую строку через небольшой скрипт. Проще всего это делать в PowerShell, который есть в современных версиях Windows.
Готовый журнал полезен в разговоре с провайдером: вы называете конкретное время обрыва и приводите строки с потерями, а не рассказываете о вечернем «подвисании».
Есть и организационная сторона. Служба поддержки чаще реагирует на конкретику: «между 21:14:05 и 21:14:31 пропали двадцать шесть ответов подряд». Такое сообщение можно проверить на стороне оборудования, тогда как жалобу на «плохой интернет вечером» разобрать почти невозможно.
Команда для PowerShell с записью в файл
Откройте PowerShell и выполните одну строку (пример, адрес из блока документации):
ping -t 192.0.2.1 | ForEach-Object { "{0} {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $_ } | Tee-Object -FilePath C:\Temp\ping-log.txt -Append
Что здесь происходит, по частям:
| Фрагмент | Назначение |
|---|---|
| ping -t 192.0.2.1 | Непрерывная проверка выбранного узла |
| ForEach-Object { ... } | Обработка каждой строки вывода по очереди |
| Get-Date -Format "..." | Получение текущей даты и времени в удобном формате |
| Tee-Object -FilePath ... -Append | Показ строк на экране и дописывание в файл |
Каталог C:\Temp должен существовать, иначе создайте его заранее. Остановка выполняется сочетанием Ctrl+C. Файл будет накапливать строки при каждом запуске, потому что указан ключ -Append.
В журнал попадут и пустые строки, и заголовок «Обмен пакетами с…», это нормально. Для чтения удобно искать в файле слова «Превышен интервал» или «Request timed out» в зависимости от языка системы.
Если путь с пробелами, возьмите его в кавычки. Для проверки работы конвейера сначала запустите тест на минуту и откройте файл: убедитесь, что строки идут с датой и временем, и только потом оставляйте проверку на ночь.
Вариант через командную строку и простой отбор ошибок
Если PowerShell недоступен, метку можно получить циклом в командной строке, но синтаксис громоздкий и разные локали выводят дату по-разному. Поэтому мы рекомендуем PowerShell, а cmd используем лишь для простой записи без времени: ping -t 192.0.2.1 > C:\Temp\ping.txt. Здесь метки времени нет, но по файлу можно оценить количество потерь.
Чтобы после долгого теста быстро найти только проблемные строки, отфильтруйте журнал в PowerShell:
Select-String -Path C:\Temp\ping-log.txt -Pattern "Превышен|недоступен|timed out|unreachable"
Команда покажет строки с ошибками вместе со временем. Сразу видно, сгруппированы ли потери в одну минуту (вероятно, короткий обрыв) или размазаны по всему периоду (вероятно, слабый сигнал или перегрузка).
Не забудьте, что при переходе компьютера в спящий режим ping приостанавливается, и в журнале появится провал, не связанный с сетью. Отключите сон на время теста в параметрах электропитания.
Если журнал получился большим, вычислите общее число потерь командой (Select-String -Path C:\Temp\ping-log.txt -Pattern "Превышен").Count. Оценив число потерянных ответов относительно общего числа строк, вы получите приблизительный процент потерь за весь период наблюдения.
Что именно и откуда пинговать
От выбора узла зависит смысл журнала. Для локализации проблемы используйте несколько параллельных окон с разными целями.
- Шлюз по умолчанию (адрес роутера): показывает состояние локальной сети и Wi-Fi.
- Первый внешний узел провайдера, если он известен по трассировке: показывает состояние линии до провайдера.
- Публичный узел с устойчивым ответом: показывает общую связность.
Если потери начинаются уже на шлюзе, причина в вашей локальной сети или радиоканале. Если шлюз отвечает ровно, а внешний узел теряет пакеты, ищите проблему за пределами квартиры. Так журнал превращается в инструмент диагностики, а не просто в записи. Порядок разбора внешнего маршрута описан на страницах про tracert и mtr.
Пингуйте только свои устройства и общедоступные узлы, не используйте частые запросы к чужим серверам.
Запускайте измерение в то время, когда обычно возникает проблема, и по возможности с проводным подключением, чтобы отделить неполадки Wi-Fi от проблем линии. Сравнение проводного и беспроводного журналов за один и тот же час часто сразу показывает виновника.
Аналоги для Linux и macOS
В Linux с пакетом iputils есть ключ -D: он печатает перед каждой строкой время в виде числа секунд с начала эпохи Unix, что удобно для последующей обработки. Запись в файл выполняется командой ping -D 192.0.2.1 | tee ping.log. Если нужно человекочитаемое время, каждую строку можно пропускать через цикл while read с вызовом date, но при обработке через канал вывод иногда идёт порциями из-за буферизации.
В macOS ключа -D для этой цели нет (там он запрещает фрагментацию), поэтому время добавляют внешним циклом с командой date.
Итоговое правило одинаково для всех систем: метку времени должен добавлять не ping, а обвязка вокруг него. Делайте журнал коротким по времени наблюдения и понятным по формату, чтобы его прочитал и человек, и скрипт. Для регулярного мониторинга стоит рассмотреть специализированные системы, ping в файле подходит для разовой диагностики.