Любая программа ведёт дневник. Каждый вход в систему, каждая нажатая кнопка, каждая ошибка и каждый перезапуск сервиса ложатся строкой в текстовый файл, который потом никто не открывает. До первого сбоя.
Когда сайт отдаёт белый экран, приложение вылетает на старте, а бухгалтерия говорит «у нас всё пропало», ответ почти всегда уже записан. Он лежит в логах, и надо только знать, где искать и как читать. Любой сбой оставляет след. В этой статье разберём, что такое лог файл, какие бывают типы логов, как устроена одна строка внутри, где лежат логи на Windows и на сервере, чем открыть файл на два гигабайта и как за пять шагов найти причину падения.
Если по дороге встретите незнакомое слово, не пугайтесь: технические термины расшифровываем прямо в тексте. Отдельно пригодится разбор кодов ответов сервера, потому что именно эти трёхзначные числа вы увидите в логах веб-сервера чаще всего.
Статья пригодится не только программистам. Логи читают тестировщики, аналитики, специалисты по безопасности, техподдержка и все, кто когда-нибудь получал от разработчика просьбу «пришлите лог». Чаще всех с ними работает системный администратор: для него это основной рабочий инструмент, а не разовая необходимость.
А если захочется освоить это системно, у нас собрана подборка курсов системного администрирования: от коротких интенсивов по Linux до годовых программ с трудоустройством.
CheckroiПодборка курсов для системных администраторов109 курсов • 26 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Что такое лог-файл и почему его называют чёрным ящиком
Лог-файл (от английского log, «судовой журнал») — это файл, куда программа автоматически записывает всё, что с ней происходит, в хронологическом порядке. Русское название точнее: журнал событий. Каждая запись отвечает на три вопроса: когда что-то случилось, что именно случилось и насколько это важно.
Сам процесс записи называют логированием. Программист заранее расставляет в коде команды вида «запиши в журнал, что пользователь вошёл» или «запиши, что не удалось подключиться к базе». Дальше программа делает это сама, без участия человека, круглые сутки.
Аналогия с чёрным ящиком самолёта работает почти дословно. Пока полёт идёт нормально, записи никому не нужны и просто копятся. Когда что-то ломается, единственный способ понять причину: поднять журнал и посмотреть, что происходило за минуту до аварии.
Ключевая мысль. Лог отвечает на вопрос «что происходило в системе в 14:32», а не «что сломано прямо сейчас». Это запись прошлого, поэтому её ценность целиком зависит от того, включили ли логирование заранее.
Физически чаще всего это обычный текстовый файл с расширением .log. Открывается блокнотом, читается глазами, ищется поиском. Иногда логи пишут в двоичном виде (набор байтов, который человек не прочтёт напрямую) или сразу в базу данных, и тогда нужна отдельная программа-просмотрщик. Но принцип везде одинаковый: одна строка равна одному событию.
Зачем нужны логи: четыре задачи, которые они закрывают
Логи собирают не потому, что так принято. У них четыре вполне денежные задачи.
Найти причину сбоя. Самое частое применение. Приложение упало, сайт отдал ошибку, платёж не прошёл. В логе будет точное время и текст ошибки, часто вместе с стек-трейсом (списком функций, через которые программа шла до момента падения). Без этого поиск причины превращается в гадание.
Понять, что было до сбоя. Ошибка редко возникает на пустом месте. За минуту до неё в журнале обычно видно предупреждения: закончилось место на диске, база отвечала медленно, сервис перезапускался четыре раза подряд. Эта цепочка и есть настоящая причина.
Отследить безопасность. Логи фиксируют, кто, когда и с какого адреса заходил в систему. Триста неудачных попыток входа за десять минут с одного адреса означают, что пароль пытаются подобрать перебором. Для расследования инцидента журнал доступа часто оказывается единственным доказательством. Этим занимается специалист по кибербезопасности, но заметить аномалию может кто угодно.
Посчитать нагрузку и поведение. По журналу веб-сервера видно, сколько было запросов, какие страницы открывали чаще, откуда пришли люди и в какой момент нагрузка выросла вдвое. Это чистая аналитика, которую можно получить без счётчиков и внешних сервисов.
Канал основателя Checkroi Вани Буявца3 700 человек читают мой Телеграм-канал про нейросетиСобрал промпты для Claude Code и ChatGPT, разборы ИИ-инструментов и лайфхаки по продвижению бизнеса в одном местеПрисоединитьсяВиды логов: какие бывают журналы событий
Классификаций много, но на практике вам встретятся пять видов логов.
Системные логи пишет сама операционная система: запуск и остановка служб, подключение устройств, проблемы с диском и памятью. В Linux это /var/log/syslog и журнал systemd (менеджера служб, который управляет запуском всех фоновых программ), а в Windows это журналы «Система» в Просмотре событий.
Логи приложений ведут отдельные программы: 1С, CRM, мобильное приложение, ваш интернет-магазин. Что в них попадёт, решает разработчик, поэтому качество сильно разнится: где-то подробная картина, где-то две строки в сутки.
Логи веб-сервера делятся на два файла. Access log (журнал доступа) содержит все обращения к сайту: адрес посетителя, время, запрошенную страницу, код ответа. Error log (журнал ошибок) собирает только проблемы: битые скрипты, отсутствующие файлы, отказы обработчика.
Логи безопасности отвечают за входы, смену прав и доступ к файлам. В Linux это /var/log/auth.log, в Windows журнал «Безопасность».
Логи баз данных фиксируют медленные запросы, ошибки соединения и изменения структуры. По ним чаще всего понимают, почему сайт стал открываться семь секунд вместо одной.
Как читать лог-файл: разбираем строку по полям
Здесь застревает большинство новичков. Открываешь большой файл, видишь стену одинаковых строк и не понимаешь, с чего начинать. На самом деле строка почти всегда собрана по одному шаблону, и достаточно один раз разобрать её по полям.
Строка журнала доступа веб-сервера
Самый частый формат, его использует и nginx, и Apache:
93.158.24.11 - - [05/Sep/2026:14:32:15 +0300] "GET /catalog/shoes HTTP/1.1" 200 15243 "https://yandex.ru/" "Mozilla/5.0"
Читается слева направо:
93.158.24.11— IP-адрес того, кто пришёл на сайт[05/Sep/2026:14:32:15 +0300]— timestamp, метка времени;+0300означает московский часовой поясGET /catalog/shoes— что человек запросил: метод и адрес страницы200— код ответа. Это главное поле в строке: 200 значит «всё хорошо», 404 сообщает, что страницы нет, 500 говорит о поломке на сервере15243— сколько байт отдал сервер"https://yandex.ru/"— откуда пришёл посетитель"Mozilla/5.0"— браузер или робот
Уже по одной такой строке видно: человек из Яндекса открыл каталог обуви в 14:32, страница отдалась нормально. А если бы в поле кода стояло 500, вы бы точно знали время и адрес сломавшейся страницы.
Строка системного журнала
Sep 5 14:30:12 srv01 nginx[1284]: [error] connect() failed (111: Connection refused)
Полей меньше: дата и время, имя сервера (srv01), имя программы и её номер процесса (nginx[1284]), уровень важности и текст события. Тут прямым текстом написано, что nginx не смог подключиться к другой программе и получил отказ.
Структурированный лог в формате JSON
JSON — это способ записать данные парами «название поля: значение». Такой лог сложнее читать глазами, зато его легко ищет и фильтрует программа:
{"timestamp":"2026-09-05T14:32:18Z","level":"ERROR","service":"payment","user_id":4821,"message":"Card declined","request_id":"a7f3c9"}
Обратите внимание на request_id: это сквозной номер запроса. Один клик пользователя проходит через пять разных сервисов, и по общему номеру собирается вся цепочка. В больших системах это спасает время.
Правило чтения. Не пытайтесь прочесть лог целиком. Найдите время проблемы, отмотайте на пару минут назад и читайте только этот отрезок. Всё остальное почти наверняка фоновый шум.
Уровни логирования: от TRACE до FATAL
Чтобы журнал не превращался в свалку, каждой записи присваивают уровень логирования, метку важности. Она стоит в начале строки в квадратных скобках или отдельным полем.
| Уровень | Что означает | Нужна ли реакция |
|---|---|---|
| TRACE | Самая подробная запись: каждый шаг программы | Нет, включают только при отладке |
| DEBUG | Технические детали для разработчика: значения переменных, вызовы функций | Нет, в обычном режиме выключен |
| INFO | Обычные события: сервис запустился, пользователь вошёл, заказ создан | Нет, это норма |
| WARN | Что-то подозрительное, но программа работает: диск заполнен на 85 %, база отвечает медленно | Посмотреть в рабочее время |
| ERROR | Операция не выполнена: платёж не прошёл, письмо не отправилось | Да, разбираться сегодня |
| FATAL / CRITICAL | Программа не может продолжать работу и останавливается | Да, немедленно |
Уровни работают как фильтр по порогу. Если в настройках выставлен уровень WARN, в файл попадут только WARN, ERROR и FATAL, а всё, что ниже, отбросится. Поэтому в обычной работе держат INFO, а DEBUG включают точечно, когда ловят конкретный баг: на подробном уровне файл растёт гигабайтами в час.
Если непонятно, с чего начинать чтение, ищите строки с ERROR и FATAL. В девяти случаях из десяти причина сбоя окажется в первом же ERROR после того момента, когда всё ещё работало.
Где искать логи на компьютере и на сервере
Второй частый вопрос: логи-то есть, но где именно лежат.
Windows
Основной инструмент называется Просмотр событий (Event Viewer). Нажмите Win+R, введите eventvwr и откройте раздел «Журналы Windows». Внутри четыре папки: «Система» (драйверы и службы), «Приложение» (обычные программы), «Безопасность» (входы и доступ к файлам), «Установка».
Логи отдельных программ Windows часто кладёт рядом с собой или в папку пользователя: загляните в C:\ProgramData\ИмяПрограммы\ и C:\Users\Имя\AppData\Local\ИмяПрограммы\.
Linux и macOS
Стандартное место: папка /var/log. Там же лежат подпапки конкретных сервисов. Чаще всего нужны:
/var/log/syslogили/var/log/messages— общесистемные события/var/log/auth.log— входы и попытки подбора пароля/var/log/nginx/и/var/log/apache2/— веб-сервер/var/log/mysql/— база данных
В свежих версиях Linux часть журналов лежит внутри systemd и читается командой journalctl -u имя_сервиса. Базовый набор команд для такой работы мы собрали в шпаргалке из 27 команд Linux. Разбираться с ними по работе приходится в первую очередь тем, кто идёт в администрирование Linux.
Веб-сервер
Если путь по умолчанию не подошёл, точный адрес всегда записан в конфигурации. У nginx это директивы access_log и error_log в файле /etc/nginx/nginx.conf, у Apache это строки CustomLog и ErrorLog в httpd.conf или apache2.conf. На хостинге логи обычно доступны прямо из панели управления в разделе «Журналы».
Мобильные приложения и браузер
В браузере роль лога играет консоль разработчика: F12, вкладка Console. Там видно ошибки скриптов на странице. У мобильных приложений журнал собирается на устройстве и отправляется разработчику при нажатии «Сообщить о проблеме». Когда вас просят «прислать логи», чаще всего имеют в виду именно этот пункт меню.
Канал основателя Checkroi Вани БуявцаЗабирайте промпты и обучение по нейросетям в моём Телеграм-каналеБольше 3 700 человек уже применяют Claude Code, ChatGPT и другие нейросети в работе, учёбе, бизнесе и жизниПерейти в каналЧем открыть лог-файл
Расширение .log не привязано ни к какой конкретной программе. Внутри обычный текст, поэтому открывает его почти всё.
Файл до 50 МБ. Подойдёт «Блокнот», но лучше взять Notepad++ или VS Code: они подсвечивают синтаксис, умеют искать по всему файлу и не портят кодировку. На macOS и Linux подойдёт любой текстовый редактор или команда less.
Файл на сотни мегабайт или гигабайты. Обычный редактор пытается загрузить всё содержимое в память и зависает. Нужны просмотрщики, которые читают файл кусками прямо с диска: glogg, Large Text File Viewer, LogExpert. В командной строке ту же задачу решают tail и grep, о них ниже.
Файл нечитаемый, сплошные значки. Значит, лог двоичный, и его нужно открывать штатной программой того сервиса, который его создал. Второй вариант: файл текстовый, но в другой кодировке. Попробуйте переключить кодировку на UTF-8 или Windows-1251 в редакторе.
CheckroiПодборка курсов по тестированию ПО101 курс • 26 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Как найти причину сбоя по логам за пять шагов
Допустим, интернет-магазин перестал открываться в районе трёх часов дня. Порядок действий выглядит так.
Шаг 1. Зафиксируйте время. Спросите у того, кто заметил проблему, когда именно всё сломалось, хотя бы с точностью до десяти минут. Без этого вы будете читать журнал наугад. Проверьте заодно, в каком часовом поясе пишет сервер: расхождение на три часа между московским временем и UTC путает чаще всего.
Шаг 2. Выберите нужный журнал. Сайт не открывается совсем: смотрите error log веб-сервера. Открывается, но выдаёт ошибку на конкретной странице: лог приложения. Всё тормозит: лог базы данных. Сервер перезагрузился сам: системный журнал.
Шаг 3. Отмотайте на пять минут назад от момента сбоя и читайте подряд. Чтобы найти ошибку, ищите первую строку с уровнем ERROR или FATAL. Именно первую: дальше обычно идут её последствия, а не новые причины.
Шаг 4. Отфильтруйте шум. В командной строке это две команды. grep ERROR /var/log/nginx/error.log покажет только строки с ошибками, а tail -f /var/log/nginx/error.log будет показывать новые записи в живом режиме, пока вы воспроизводите проблему. Второй приём особенно полезен: нажимаете кнопку в интерфейсе и сразу видите, что появилось в журнале.
Шаг 5. Проверьте очевидное. Прежде чем углубляться, посмотрите на три вещи, которые дают больше половины всех аварий: закончилось место на диске, истёк сертификат, упала база данных. Все три оставляют в логах прямые сообщения открытым текстом.
Из практики. Самая частая ошибка новичка: начинать чтение с последней строки файла. Последняя строка почти всегда описывает финальное следствие, а не причину. Настоящий виновник записан на несколько минут раньше.
Ротация и сроки хранения: почему логи забивают диск
Журнал пишется непрерывно и растёт бесконечно. Активный сайт легко даёт несколько гигабайт логов в сутки, и рано или поздно место на диске заканчивается. Тогда падает уже всё сразу, включая сам сайт.
Проблему решает ротация: старый файл закрывается, переименовывается и сжимается, а запись продолжается в новый. В Linux этим занимается утилита logrotate, она запускается по расписанию и работает по простым правилам: как часто резать (обычно раз в сутки или по достижении размера), сколько старых копий хранить, сжимать ли их в архив.
Выглядит результат так: access.log — текущий, access.log.1 — вчерашний, access.log.2.gz — позавчерашний в сжатом виде. Копии старше заданного числа logrotate удаляет сам.
Сколько хранить. Единого норматива нет, но ориентиры такие: технические логи приложений хранят от двух недель до месяца, журналы доступа к сайту около трёх месяцев, логи безопасности и действий с персональными данными год и дольше, потому что они могут понадобиться при расследовании инцидента или проверке.
Удалять логи руками через rm не стоит по неочевидной причине. Программа продолжает держать удалённый файл открытым, и место на диске не освобождается до перезапуска сервиса. Правильнее либо настроить logrotate, либо очистить содержимое файла командой truncate -s 0 имя_файла, оставив сам файл на месте.
Что в логах писать нельзя
Логи читают разработчики, админы, подрядчики и системы мониторинга. Всё, что туда попало, считайте условно публичным внутри компании. Поэтому есть короткий список того, чего в журнале быть не должно.
- Пароли и токены доступа в любом виде, включая «временно, для отладки»
- Номера банковских карт и CVV: это прямое нарушение стандартов платёжной индустрии
- Паспортные данные, СНИЛС, полные ФИО вместе с адресом
- Медицинские сведения и другие особые категории данных
В России обработка таких данных регулируется законом № 152-ФЗ. Он не называет конкретный срок хранения логов, но требует, чтобы персональные данные хранились не дольше, чем нужно для заявленной цели, и были защищены от посторонних. Журнал с паспортами в открытом виде под это требование не подходит.
Рабочий приём: писать в лог идентификатор вместо самих данных. Вместо user=Иванов Иван, card=4276... в журнал уходит user_id=4821, card_last4=1234. Этого хватает, чтобы найти нужный заказ в базе, и не хватает, чтобы украсть данные из файла.
Когда одного файла уже мало: ELK, Loki и Graylog простыми словами
Пока у вас один сервер, хватает tail и grep. Когда серверов становится десять, а сервисов тридцать, начинается неприятное: чтобы собрать историю одного заказа, надо зайти на пять машин и вручную сопоставить время в пяти разных файлах.
Задачу решают системы сбора логов. Работают они одинаково: на каждый сервер ставится маленькая программа-сборщик, она отправляет строки в общее хранилище, а вы ищете по всем серверам сразу через веб-интерфейс. Это называется агрегацией логов.
| Система | Что это | Кому подходит |
|---|---|---|
| ELK Stack | Связка Elasticsearch (поиск), Logstash (обработка) и Kibana (интерфейс) | Крупным проектам, где нужен сложный поиск и графики |
| Grafana Loki | Лёгкое хранилище логов, индексирует только метки, а не текст целиком | Небольшим командам, экономит место и деньги на дисках |
| Graylog | Готовая платформа со сбором, поиском и оповещениями из коробки | Тем, кто хочет запустить быстро и без долгой настройки |
Если непонятно, что выбрать, начните с Grafana Loki: она проще в запуске и дешевле в обслуживании, а её интерфейс Grafana вы, скорее всего, уже видели. ELK берут, когда объёмы вырастают и нужен полнотекстовый поиск по всему содержимому.
CheckroiПодборка курсов по Grafana66 курсов • 14 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Поверх этого настраивают алерты: правила вида «если за пять минут появилось больше двадцати строк с ERROR, напиши в Telegram». После этого о проблеме вы узнаёте раньше клиентов. Строят такие системы DevOps-инженеры, а сами инструменты входят почти в любую программу курсов по DevOps.
Кому логи нужны по работе
Навык чтения логов пригодится шире, чем кажется.
Системный администратор живёт в логах ежедневно: следит за здоровьем серверов, ловит попытки взлома, разбирает падения сервисов.
DevOps-инженер проектирует, как логи собираются и хранятся во всей инфраструктуре, и настраивает оповещения.
Тестировщик прикладывает лог к баг-репорту. Отчёт «кнопка не работает» разработчик вернёт с вопросами. Отчёт со строкой ошибки и точным временем возьмут в работу сразу. Это одно из первых требований на собеседовании, если вы идёте в тестирование.
Разработчик решает, что писать в журнал. От этого зависит, найдёт ли кто-нибудь причину аварии через полгода.
Специалист по безопасности строит на логах расследования инцидентов и настраивает обнаружение аномалий. Работа с журналами доступа входит в базу обучения кибербезопасности.
Аналитик и SEO-специалист читают журнал доступа веб-сервера, чтобы увидеть, как по сайту ходят поисковые роботы и какие страницы отдают ошибки.
Где научиться работать с логами
Отдельного курса «чтение логов» не существует: это часть базы системного администрирования, DevOps и тестирования. Разбираться самому по статьям можно, но на практике быстрее выходит, когда рядом есть учебный сервер, который не жалко сломать, и преподаватель, который объяснит, почему сервис не поднялся.
Мы собрали программы, где работа с журналами, мониторингом и инфраструктурой разобрана на реальных задачах.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Профессия «Системный администратор» Перейти на сайт курса |  Нетология | 84 400 ₽ | 5125 ₽/мес. | 11 месяцев | Обзор курса |
| Системный администратор Перейти на сайт курса |  GeekBrains | 99 500 ₽ | 2764 ₽/мес. | 7 месяцев | Обзор курса |
| Системный администратор (Бакалавриат) Перейти на сайт курса |  Университет Синергия | 440 000 ₽ | 36 667 ₽/мес. | 3 years | Обзор курса |
| Онлайн-курс Системный администратор Перейти на сайт курса |  Бруноям | 65 900 ₽ | 5491 ₽/мес. | 6 месяцев | Обзор курса |
| Системный администратор windows - курс переподготовки Перейти на сайт курса |  АПОК | 32 980 ₽ | 2748 ₽/мес. | 400 часов | Обзор курса |
| Системный администратор Перейти на сайт курса |  Яндекс Практикум | 115 500 ₽ | 4531 ₽/мес. | 6 месяцев | Обзор курса |
| Системный администратор Перейти на сайт курса |  OnSkills | 1900 ₽ | 475 ₽/мес. | Обзор курса | |
| Системный администратор linux - курс переподготовки Перейти на сайт курса | АПОК | 32 980 ₽ | 2748 ₽/мес. | 400 часов | Обзор курса |
| Системный администратор Перейти на сайт курса |  ИПО | 36 400 ₽ | 2100 ₽/мес. | 504 часа | Обзор курса |
| Системный администратор linux Перейти на сайт курса | КИДПО | 30 350 ₽ | 2529 ₽/мес. | 256 часов | Обзор курса |
Больше программ — в полном каталоге курсов для системных администраторов
Если хочется сначала понять, куда идти, посмотрите обзоры смежных профессий: системный администратор, DevOps-инженер и администратор Linux отличаются задачами и зарплатной вилкой сильнее, чем кажется со стороны.
