Логи в Linux: когда искать в journalctl, а когда — в файлах

Когда сервис в Linux перестаёт отвечать, команда tail -f /var/log/... может показать пустоту — не потому, что ошибки нет, а потому, что сообщения лежат в системном журнале. А приложение, наоборот, может писать только в собственный файл. Ниже — практический маршрут для systemd 252 и новее: как выбрать источник, сузить поиск и сопоставить записи, не тратя время на просмотр всего каталога /var/log.

Сначала определите, где пишет сервис

В Linux нет одного обязательного места для всех логов. systemd-journald собирает сообщения служб и ядра в журнал. Приложение также может писать в файл — напрямую или через отдельный логгер. Некоторые службы передают вывод в journald, но сохраняют свои журналы и на диске. Поэтому «journalctl или файлы» — не всегда выбор одного варианта: иногда нужны оба.

Начните с имени systemd-службы и проверьте журнал:

sudo journalctl -u nginx -n 100 --no-pager

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

Файловые логи ищите по документации конкретного приложения и его конфигурации. Каталог /var/log — привычное место, но не гарантия: путь и формат задаёт программа или её администратор.

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

Два источника — две разные задачи

Термин. Ротация логов — это перенос или переименование старого файла с созданием нового; старые записи могут оказаться в архиве, иногда сжатом. Поэтому текущий error.log не всегда содержит нужный период.

Маршрут поиска через journalctl

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

sudo journalctl -u nginx --since="1 hour ago" --no-pager

Чтобы наблюдать за новыми сообщениями во время повторения ошибки, добавьте режим слежения:

sudo journalctl -u nginx -f

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

sudo journalctl --list-boots
sudo journalctl -b -1 -p warning --no-pager

-b -1 выбирает предыдущую загрузку, а -p warning оставляет предупреждения и более серьёзные сообщения. Если предыдущая загрузка недоступна, это может быть связано с настройками хранения журнала: записи не обязательно сохраняются между перезагрузками.

Когда переходить к файлам

Если приложение документирует отдельный лог-файл или в журнале нет нужной подробности, читайте файл напрямую. Например, для настроенного файла ошибок Nginx:

sudo tail -n 200 /var/log/nginx/error.log
sudo tail -f /var/log/nginx/error.log

Первой командой получите последние 200 строк, второй — новые записи по мере появления. Путь здесь пример для типовой установки: проверьте конфигурацию, если файла нет. Ищите конкретную фразу так:

sudo grep -n 'upstream timed out' /var/log/nginx/error.log

Если ошибка возникла раньше, текущий файл мог пройти ротацию. Посмотрите соседние файлы с суффиксами даты или номера и архивы; сжатые журналы обычно требуют отдельной команды чтения, например zgrep, если она установлена. Не удаляйте архивы, пока не проверили, что в них нет нужного периода.

Когда что выбирать

• Служба под systemd, нужно быстро увидеть последние ошибки. Начните с journalctl -u имя-службы, ограничьте вывод периодом и уровнем важности.
• Приложение указывает собственный файл. Читайте именно его, а не случайный журнал из /var/log. Для долгого разбора проверьте ротированные копии.
• Нужно восстановить последовательность события. Сопоставьте сообщения службы в journalctl с записями приложения по времени. Учитывайте часовой пояс и точность временных меток.

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

Что ломается при поиске

Служба называется не так, как вы ожидаете

Имя процесса, пакета и systemd-службы могут различаться. Найдите фактическое имя в списке служб или документации установленного приложения и повторите запрос. Не делайте вывод о наличии логов по одному запросу с предположительным именем.

Команда ничего не показывает

Проверьте период поиска, права доступа и имя службы. Для диагностики используйте sudo, если у вас есть административные права. Если журнал пуст и после этого, выясните, куда приложение направляет вывод и не ограничивает ли хранение доступный период.

В файле нет старой ошибки

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

Поиск выдаёт слишком много строк

Фильтруйте по службе, времени и при необходимости уровню важности. Не ограничивайтесь только ошибками: предупреждение перед сбоем может объяснить причину. Зафиксируйте временной диапазон и повторите запрос уже с ним.

Права и срок хранения

Доступ к системному журналу зависит от дистрибутива, групп пользователя и настроек машины. Если без sudo команда не показывает часть записей, это не обязательно проблема journald. Не меняйте права на журналы и не добавляйте пользователя в привилегированные группы только ради удобства: сначала согласуйте доступ с администратором.

Объём и срок хранения журнала тоже не универсальны: на них влияют настройки journald и свободное место. Команда journalctl --disk-usage показывает занимаемый журналом объём. Перед очисткой проверьте, не нужны ли записи для расследования инцидента или требований вашей организации. Настройки хранения и очистки относятся к отдельной задаче; не используйте удаление как способ «починить» поиск.

Что делать дальше

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

Документация. Список параметров команды и описание конфигурации journald могут различаться между версиями systemd; сверяйтесь с руководством для установленной версии.