Системные журналы: где искать причины сбоев в Windows и Linux

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

Записи делят по уровням важности: информационные, предупреждения, ошибки и критические. В обычной работе ошибки встречаются часто, и не каждая из них связана с вашей проблемой, поэтому ключ к анализу — сопоставить запись со временем сбоя.

Полезно помнить, что время в журналах может храниться в разных часовых поясах: в системе оно чаще локальное, а в файлах серверов нередко в UTC. Сверяйте поясa, иначе можно «промахнуться» на несколько часов и искать событие не там.

Средство просмотра событий открывается командой eventvwr в окне «Выполнить». В разделе «Журналы Windows» находятся «Система» (драйверы, службы, оборудование), «Приложение» (программы) и «Безопасность» (входы и аудит). Ниже есть «Журналы приложений и служб» с разделами по компонентам, например WLAN-AutoConfig для Wi-Fi.

У события есть источник, идентификатор и уровень. Фильтр по времени и уровню оставляет только нужное, а по идентификатору события можно найти пояснение. Экспортировать выбранные записи можно в файл для передачи специалисту.

Отдельно стоит подраздел «Диагностика» в журналах приложений: там, например, фиксируются события оператора беспроводной сети и сбои, приводившие к автоматическому восстановлению. Эти записи оказываются самыми точными для проблем с Wi-Fi и драйверами.

В современных дистрибутивах с systemd записи читают командой journalctl: с ключом -b — за текущую загрузку, -u имя — по службе, -p err — только ошибки. Классические текстовые файлы, где они есть, лежат в /var/log: syslog или messages для общих событий, auth.log или secure для входов, kern.log для ядра. Команда dmesg выводит сообщения ядра, полезные при проблемах с драйверами и оборудованием.

Для чтения файлов подойдёт less, tail -f для наблюдения за новыми записями и grep для поиска по ключевому слову.

Записи в файлах обычно идут по времени сверху вниз, поэтому свежие события находятся в конце: команда tail -n 100 быстро покажет последние строки, а поиск по слову error или failed сужает круг.

Если пропал Wi-Fi, ищите события WLAN и драйвера в момент сбоя. Если сервис не запускается, откройте записи этой службы: в них часто прямо указано, что порт занят, файл не найден или не хватает прав. Разрывы соединения бывают связаны с перезапуском адаптера, что тоже отображено во времени.

Советуют идти от времени сбоя: запомните момент, отступите на минуту назад и читайте вперёд. Повторяющиеся ошибки с одним кодом важнее одиночных.

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

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

Опасное заблуждение — очищать журнал «для скорости». Эффекта нет, а после очистки исчезают следы, нужные для диагностики и расследования инцидентов. Злоумышленники, напротив, часто стирают журналы, чтобы скрыть присутствие, и внезапная очистка сама может быть тревожным признаком.

В Windows откройте просмотр событий, выберите «Система», отфильтруйте по уровням «Ошибка» и «Критический» за последний час. В Linux выполните journalctl -p err -b. Найдите записи около времени сбоя, скопируйте текст сообщения и код: они пригодятся для поиска решения. Сохраните нужные записи, прежде чем перезагружать компьютер.

Если проблема повторяется, воспроизведите её и сразу же откройте журнал: свежие записи проще сопоставить с действием. Для длительных наблюдений включайте запись в файл и сравнивайте результаты по времени.