Логи Linux: где искать и как читать (journalctl и /var/log)

Два разных источника логов на одном сервере

На типичном современном Linux-сервере логи одновременно живут в двух параллельных системах, и путаница между ними — частая причина потерянного времени при разборе проблемы. Первая система — классические текстовые файлы в каталоге /var/log, куда десятилетиями писали свои логи почти все Unix-программы. Вторая — системный журнал (journal), который ведёт systemd, начиная с сервисов, запущенных именно через systemd-юниты, и заканчивая сообщениями самого ядра.

Исторически каждая служба сама решала, куда и в каком формате писать собственный лог — nginx пишет в /var/log/nginx, MySQL в /var/log/mysql, почтовый сервер в /var/log/mail.log, и единого стандарта форматирования между ними не было и до сих пор в основном нет. systemd, появившийся позже как система инициализации, принёс с собой journald — демон, который собирает вывод (stdout и stderr) любого управляемого systemd сервиса в единый бинарный журнал с общими, куда более богатыми метаданными: точным временем с точностью до микросекунд, PID процесса, именем юнита, приоритетом сообщения и рядом других полей.

На практике оба источника продолжают сосуществовать: часть служб (особенно старые или явно настроенные так) по-прежнему пишут собственные файлы в /var/log параллельно с тем, что уже попадает в journal через стандартный вывод процесса, а часть логов — например, вывод самого ядра при загрузке или события systemd о запуске и остановке служб — доступны практически только через journalctl, поскольку никогда не существовали в виде отдельного текстового файла.

Эта статья разбирает, как читать оба источника эффективно: ключевые флаги journalctl для сужения огромного потока записей до нужных, наиболее часто нужные файлы в /var/log, приёмы grep для быстрого поиска, и практический порядок действий на случай, когда сайт или сервис вдруг перестал работать, а причина не очевидна.

journalctl: основы работы с системным журналом

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

journalctl | wc -l

Самый частый и полезный флаг — -u с именем systemd-юнита, который отфильтровывает журнал так, что остаются только записи, относящиеся к конкретной службе. Имя юнита не всегда совпадает с интуитивно ожидаемым названием программы — точное имя удобно узнать командой systemctl list-units, которая покажет полный список активных на сервере служб.

journalctl -u nginx\njournalctl -u mysql\njournalctl -u php8.3-fpm

По умолчанию journalctl выводит записи постранично через встроенный пейджер (обычно less), что позволяет листать вывод, искать по нему нажатием клавиши / и переходить в конец нажатием Shift+G — теми же приёмами, что при работе с less в любом другом контексте. Флаг --no-pager отключает постраничный вывод и печатает всё сразу в терминал, что удобнее, если вывод затем перенаправляется в файл или передаётся дальше по конвейеру в grep.

Слежение за логом в реальном времени: -f

Флаг -f (follow) переключает journalctl в режим слежения — команда не завершается, а продолжает выводить новые записи по мере их появления, аналогично классической команде tail -f для обычного текстового файла. Это незаменимо, когда нужно увидеть эффект от конкретного действия прямо в момент его выполнения, а не искать его задним числом среди уже накопившихся записей.

journalctl -f -u nginx

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

Комбинировать -f можно и с несколькими юнитами одновременно, указав -u несколько раз, — удобно, когда проблема может находиться на стыке двух сервисов (например, nginx и php-fpm), и нужно видеть записи обеих служб вперемешку в едином хронологическом порядке, не переключаясь между двумя отдельными терминалами.

journalctl -f -u nginx -u php8.3-fpm

Фильтрация по времени: -b, --since и --until

Флаг -b ограничивает вывод текущей загрузкой системы (boot) — удобно сразу после перезагрузки сервера, когда нужно исключить из вывода все записи от предыдущих сессий его работы и увидеть только то, что произошло с момента последнего старта. Если серверу нужно посмотреть предпоследнюю загрузку, а не текущую, используется -b -1, для более ранних — соответственно -b -2 и так далее.

journalctl -b\njournalctl -b -1 -u mysql

Флаги --since и --until задают произвольный временной диапазон в человекочитаемом формате, включая относительные значения вроде «1 hour ago» или «yesterday», что часто удобнее, чем указывать точную дату и время вручную. Оба флага можно комбинировать друг с другом, чтобы получить конкретное окно времени, а не только «от указанного момента и до сих пор».

journalctl --since "2026-09-22 09:00:00" --until "2026-09-22 09:30:00" -u nginx\njournalctl --since "1 hour ago"

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

Фильтрация по важности: -p и уровни severity

Каждая запись в системном журнале, как и в классическом syslog, имеет уровень важности (priority) — от отладочных сообщений (debug) до критических аварий (emerg). Флаг -p позволяет отфильтровать вывод так, чтобы остались только записи указанного уровня и выше, отбросив менее значимый информационный шум.

journalctl -p err -u nginx\njournalctl -p warning -u mysql

Полный список уровней в порядке возрастания серьёзности: debug, info, notice, warning, err, crit, alert, emerg — это тот же набор, что используется в классическом протоколе syslog, поэтому знание этих уровней пригодится и при чтении обычных текстовых логов в /var/log, где многие приложения указывают уровень важности прямо в начале каждой строки.

Практический приём для беглого осмотра состояния сервера — запросить записи уровня warning и выше сразу по всем службам без фильтра -u, что даёт компактный список потенциальных проблем со всего сервера за выбранный период, без необходимости заранее знать, какая именно служба могла быть причиной.

journalctl -p warning --since today

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

Классические логи в /var/log: где что искать

Несмотря на широкое распространение systemd и journalctl, многие ключевые для веб-проекта логи по-прежнему живут в привычных текстовых файлах внутри /var/log, и знание их типичного расположения экономит время по сравнению с попыткой найти всё через journalctl.

tail -n 100 /var/log/nginx/error.log\ntail -n 100 /var/log/nginx/access.log

Веб-сервер nginx традиционно ведёт два отдельных лога: access.log с записью о каждом обработанном запросе (адрес, метод, код ответа, время выполнения) и error.log с сообщениями об ошибках самого веб-сервера и, для PHP-FPM в конфигурации по умолчанию, также с ошибками уровня приложения, которые PHP выводит в stderr. MySQL и PostgreSQL по умолчанию также пишут собственные логи ошибок и, при явном включении, лог медленных запросов, полезный для поиска запросов, требующих оптимизации.

tail -n 100 /var/log/mysql/error.log\ntail -f /var/log/mysql/slow-query.log

Общесистемный лог аутентификации (/var/log/auth.log на Debian/Ubuntu, /var/log/secure на RHEL-совместимых дистрибутивах) фиксирует все попытки входа по SSH и через sudo — первое место для проверки при подозрении на попытки подбора пароля или незапланированный вход под неожиданной учётной записью, дополнительно к тому, что видно через journalctl -u sshd на системах с systemd.

grep и комбинация нескольких инструментов

И journalctl, и обычные текстовые логи одинаково хорошо комбинируются с grep для точечного поиска — например, чтобы найти все записи, связанные с конкретным IP-адресом, конкретным кодом ответа HTTP или конкретным сообщением об ошибке, среди тысяч строк общего лога.

grep "500" /var/log/nginx/access.log | tail -n 30\njournalctl -u nginx | grep -i "connection refused"

Флаг -i делает поиск нечувствительным к регистру, что полезно, поскольку разные компоненты системы не всегда единообразно используют заглавные и строчные буквы в сообщениях об одной и той же ошибке. Флаг -C (или отдельно -A и -B) добавляет строки контекста до и после найденного совпадения, что часто необходимо, поскольку сама по себе строка с ошибкой не всегда содержит достаточно информации без соседних строк.

grep -C 3 "PHP Fatal error" /var/log/nginx/error.log

Для логов, которые уже сжаты logrotate в файлы вида error.log.1.gz, обычный grep напрямую не сработает — для таких файлов есть отдельная утилита zgrep с идентичным синтаксисом, которая читает содержимое сжатых файлов на лету, не требуя предварительной распаковки на диск.

zgrep "Fatal error" /var/log/nginx/error.log.2.gz

Практический алгоритм: сайт не открывается, с чего начать

Когда сайт неожиданно перестал отвечать или отдаёт ошибку, полезно двигаться по цепочке слоёв от внешнего к внутреннему, а не проверять всё подряд без системы. Первый слой — веб-сервер: journalctl -u nginx (или apache) вместе с tail по error.log покажет, дошёл ли запрос вообще до сервера и что он о нём решил, включая возможные ошибки конфигурации или проблемы с сертификатом.

Если веб-сервер работает и передаёт запрос дальше без видимых ошибок, второй слой — обработчик приложения, для типичного PHP-проекта это PHP-FPM: journalctl -u php8.3-fpm покажет фатальные ошибки, вышедшее время выполнения скрипта или исчерпание лимита памяти интерпретатора, которые не всегда попадают в лог самого nginx в явном виде.

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

journalctl -u nginx -p err --since "10 minutes ago"\njournalctl -u php8.3-fpm -p err --since "10 minutes ago"\njournalctl -u mysql -p err --since "10 minutes ago"

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

Персистентность журнала и управление его размером

Системный журнал может храниться либо только в оперативной памяти (и тогда полностью пропадает при перезагрузке), либо персистентно на диске в каталоге /var/log/journal — на большинстве современных дистрибутивов персистентное хранение включено по умолчанию, но стоит явно проверить наличие этого каталога, особенно на серверах, установленных из минимальных или нестандартных образов.

ls -ld /var/log/journal\nmkdir -p /var/log/journal\nsystemctl restart systemd-journald

Журнал не растёт бесконечно — journald по умолчанию ограничивает суммарный размер занимаемого им места на диске и автоматически удаляет самые старые записи при достижении лимита. Текущее использование места журналом и явные ограничения можно посмотреть и изменить через journalctl --disk-usage и параметры в конфигурационном файле /etc/systemd/journald.conf.

journalctl --disk-usage\njournalctl --vacuum-size=500M\njournalctl --vacuum-time=30d

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

Итог: два источника, одна методика поиска

journalctl и классические файлы в /var/log решают одну и ту же задачу — дать администратору возможность понять, что именно произошло на сервере и когда, — но делают это по-разному, и знание обоих подходов, а не только одного из них, экономит время именно в тот момент, когда сервер работает не так, как ожидалось, и разбираться приходится быстро.

Главный практический навык — не запоминать наизусть путь к каждому конкретному логу, а уметь быстро сузить любой из источников по трём осям: конкретная служба (-u или конкретный файл в /var/log), временной диапазон (--since, --until, -b) и уровень важности (-p или grep по ключевым словам вроде error, fatal, warning). Эта комбинация закрывает подавляющее большинство практических случаев диагностики без необходимости листать журнал целиком.

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