Как смотреть логи сервисов через journalctl: пошаговый гайд

Введение

В современных Linux-системах управление службами и ведение журналов тесно связаны с systemd. Централизованный сбор логов выполняет демон systemd-journald, а для доступа к записям используется утилита journalctl. Она позволяет не только просматривать сообщения ядра и служб, но и фильтровать их по множеству параметров: времени, приоритету, конкретному юниту, PID и т.д. В этом руководстве мы шаг за шагом разберём, как смотреть логи сервисов через journalctl, научимся быстро находить нужные события и избегать распространённых ошибок.

Требования

• Linux-система с systemd (большинство современных дистрибутивов: Ubuntu, Debian, CentOS, Fedora, Arch и др.).

• Права суперпользователя (root) или членство в группе systemd-journal для чтения системных логов.

• Базовые навыки работы в терминале.

• Установленный пакет systemd (обычно уже есть).

Шаг 1: Проверка работы systemd-journald

Прежде чем приступить к просмотру логов, убедимся, что служба journald активна. Выполните:

systemctl status systemd-journald

В выводе должно быть указано active (running). Если служба остановлена, запустите её:

sudo systemctl start systemd-journald

Также стоит проверить, включена ли она в автозагрузку:

sudo systemctl enable systemd-journald

Шаг 2: Базовый просмотр всех логов

Самая простая команда — journalctl без аргументов. Она выведет все записи журнала в порядке возрастания времени (от старых к новым). Вывод будет открыт в пейджере less, что позволяет прокручивать и искать текст. Чтобы выйти, нажмите q.

Если вы хотите сразу увидеть последние события и следить за обновлениями в реальном времени, используйте флаг -f:

journalctl -f

Это аналог tail -f, но для журнала systemd.

Шаг 3: Просмотр логов конкретного сервиса

Для фильтрации по определённому юниту (службе) применяется опция -u или --unit. Например, чтобы посмотреть логи веб-сервера nginx:

journalctl -u nginx.service

Можно указать несколько юнитов через запятую или несколько флагов -u. Например, логи nginx и php-fpm:

journalctl -u nginx.service -u php-fpm.service

Обратите внимание: имя юнита обычно совпадает с именем службы и имеет суффикс .service. Если вы не уверены в точном имени, получите список всех юнитов командой systemctl list-units --type=service.

Шаг 4: Фильтрация по времени

journalctl поддерживает гибкие фильтры по дате и времени. Используйте опции --since и --until. Форматы могут быть разными:

• --since "2025-03-01 10:00:00" — с указанной даты и времени.

• --since yesterday — со вчерашнего дня.

• --since "1 hour ago" — за последний час.

• --until "2025-03-02 12:00:00" — до указанного момента.

Пример: логи nginx за последние 30 минут:

journalctl -u nginx.service --since "30 minutes ago"

Если время не указано, подразумевается текущий момент для --until и начало журнала для --since.

Шаг 5: Просмотр логов с определённым приоритетом

Каждое сообщение в журнале имеет приоритет (severity) от 0 (emerg) до 7 (debug). Фильтровать по уровню можно с помощью -p или --priority. Например, чтобы увидеть только ошибки и выше (crit, alert, emerg):

journalctl -p err -u nginx.service

Можно указать диапазон: -p err..alert — от ошибок до критических. По умолчанию -p включает все сообщения с указанным приоритетом и выше (более важные).

Шаг 6: Поиск по тексту сообщения

journalctl не имеет встроенного grep, но поддерживает фильтрацию по шаблону с помощью --grep (доступно в systemd 237+). Например, найти все сообщения, содержащие слово "error":

journalctl -u nginx.service --grep "error"

Если ваша версия systemd не поддерживает --grep, используйте стандартный конвейер с grep:

journalctl -u nginx.service | grep -i "error"

Учтите, что при использовании grep теряется подсветка и структурированный вывод, но это рабочий вариант.

Шаг 7: Форматирование вывода

По умолчанию journalctl выводит записи в коротком формате. Для более детального анализа можно изменить формат с помощью -o или --output. Популярные варианты:

• short — стандартный формат (по умолчанию).

• json — машиночитаемый JSON (удобно для парсинга).

• json-pretty — JSON с отступами.

• cat — только текст сообщения без метаданных.

• verbose — все поля записи.

Пример: вывести логи в формате JSON:

journalctl -u nginx.service -o json-pretty

Шаг 8: Просмотр логов за загрузку

journalctl позволяет фильтровать записи по идентификатору загрузки. Опция -b показывает логи текущей загрузки. Можно указать смещение: -b -1 — предыдущая загрузка, -b -2 — позапрошлая и т.д. Список загрузок доступен по --list-boots.

Пример: логи nginx за предыдущую загрузку:

journalctl -u nginx.service -b -1

Это полезно, если система перезагружалась и нужно найти причину сбоя.

Шаг 9: Ограничение количества строк и обратный порядок

Чтобы не прокручивать огромный вывод, используйте -n для указания числа последних строк. Например, последние 50 сообщений:

journalctl -u nginx.service -n 50

По умолчанию вывод идёт от старых к новым. Флаг -r меняет порядок на обратный (новые сверху). Это удобно в сочетании с -n:

journalctl -u nginx.service -n 50 -r

Шаг 10: Непрерывное наблюдение за логами

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

journalctl -u nginx.service -f

Также можно комбинировать с -n, чтобы сначала показать последние строки, а затем продолжить вывод:

journalctl -u nginx.service -n 20 -f

Шаг 11: Экспорт логов в файл

Иногда требуется сохранить логи для дальнейшего анализа или передачи. Используйте перенаправление вывода:

journalctl -u nginx.service --since "2025-03-01" > nginx_logs.txt

Для бинарного экспорта с возможностью последующего импорта в journalctl используйте --output=export:

journalctl -u nginx.service -o export > nginx_logs.export

Обратный импорт: journalctl --file=nginx_logs.export.

Шаг 12: Очистка журнала и управление размером

Со временем журнал может занимать много места. Проверить текущий размер можно командой:

du -sh /var/log/journal

Очистить старые записи до определённой даты:

sudo journalctl --vacuum-time=2weeks

Или ограничить общий размер:

sudo journalctl --vacuum-size=500M

Будьте осторожны: очистка необратима.

Типичные ошибки

1. Забыли указать суффикс `.service` — хотя journalctl часто понимает и без него, лучше указывать полное имя юнита. 2. Неверный формат времени в `--since`/`--until` — используйте кавычки, если в строке есть пробелы. 3. Попытка просмотреть логи без прав — обычный пользователь может не иметь доступа к системному журналу. Добавьте пользователя в группу systemd-journal или используйте sudo. 4. Использование `grep` без учёта регистра — по умолчанию grep чувствителен к регистру, добавляйте -i. 5. Очистка журнала без необходимости — всегда проверяйте, какие данные будут удалены, и делайте резервные копии важных логов. 6. Игнорирование `-b` при анализе сбоев — если система перезагружалась, логи текущей загрузки могут не содержать причину падения.

FAQ

В: Чем journalctl отличается от просмотра /var/log/syslog? О: journalctl работает с бинарным журналом systemd, который собирает логи от всех служб, ядра и самого systemd. В syslog попадают только сообщения, направленные в syslog-сокет, и формат там текстовый. journalctl даёт более структурированный доступ и мощные фильтры.

В: Как посмотреть логи сервиса, которого нет в systemd? О: Если сервис не управляется systemd, его логи могут писаться в файлы (например, /var/log/myapp.log). journalctl покажет только те сообщения, которые попали в journald (например, через stdout/stderr при запуске из systemd). Для остальных используйте обычные инструменты работы с файлами.

В: Можно ли фильтровать по PID процесса? О: Да, используйте _PID=1234 (с подчёркиванием). Например: journalctl _PID=1234. Список доступных полей можно получить с помощью journalctl -N.

В: Как сохранить цвета при перенаправлении в файл? О: journalctl не поддерживает цветной вывод при перенаправлении. Для анализа в файле цвет не нужен. Если хотите сохранить цвета для терминала, используйте --no-pager и не перенаправляйте вывод.

В: Что делать, если journalctl выдаёт "No journal files were found"? О: Возможно, журнал не ведётся (отключён в конфигурации) или у вас нет прав. Проверьте наличие директории /var/log/journal и настройки в /etc/systemd/journald.conf. Также убедитесь, что служба systemd-journald запущена.

Итог

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