journalctl от базовых фильтров до разбора инцидентов: как читать журналы Linux

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

Базовые фильтры

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

# ошибки текущей загрузки
journalctl -b -p err
# предупреждения и выше
journalctl -b -p warning | tail -50
# последние 30 минут
journalctl --since "30 min ago"
# интервал дат
journalctl --since "2026-01-01 10:00" --until "2026-01-01 12:00"

Опция -p принимает уровни: emerg, alert, crit, err, warning, notice, info, debug. В продакшене полезно убрать debug, чтобы не захлебнуться объёмом.

Фильтр по сервису

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

# журнал службы
journalctl -u nginx --since "1 hour ago"
# несколько юнитов
journalctl -u nginx -u php-fpm
# с предыдущей загрузки — сравнить поведение
journalctl -u nginx -b -1

Суффикс -b -1 незаменим после перезагрузки: по нему видно, что было до неё.

Поиск и формат вывода

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

# короткий формат
journalctl -b -p err -o short-precise | head -30
# поиск по тексту
journalctl -u ssh | grep -i "failed" | tail -20
# JSON для скриптов
journalctl -u nginx -o json -n 100 | head -5
# только сообщения ядра
journalctl -k | grep -iE "error|fail" | tail -30

Формат json удобен, когда нужно передать события в мониторинг или разобрать поля программно.

Следить за событиями в реальном времени

# поток событий с фильтром
journalctl -f -u nginx
# только ошибки
journalctl -f -p err
# сколько строк уже в журнале текущей загрузки
journalctl -b | wc -l

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

Размер и ротация журналов

По умолчанию systemd ограничивает объём журналов. Проверьте настройки, особенно на серверах с большим трафиком.

# текущее использование
journalctl --disk-usage
# настройки хранения
grep -E "^SystemMaxUse|^MaxFileSec|^MaxRetentionSec" /etc/systemd/journald.conf
# принудительная очистка старых записей (осторожно)
sudo journalctl --vacuum-time=14d
sudo journalctl --vacuum-size=500M
# проверить после очистки
journalctl --disk-usage

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

Журналы загрузки и анализ времени

Часть проблем проявляется при старте. systemd показывает, где уходит время и какие юниты не запустились.

# время загрузки
systemd-analyze
# кто дольше всех
systemd-analyze blame | head -15
# цепочки с задержками
systemd-analyze critical-chain | head -20
# неудачные юниты
systemctl --failed
journalctl -b | grep -i "failed" | head -30

Сбор данных для отчёта

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

# фрагмент за период
journalctl -u nginx --since "2 hours ago" --no-pager > nginx.log
tail -60 nginx.log
# общий снимок системы
systemctl --failed > report.txt
journalctl -b -p err >> report.txt
journalctl -b | wc -l >> report.txt

Права доступа к журналам

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

# текущий пользователь в группе?
id | tr ' ' '\n' | grep -w adm
# добавить в группу (после этого нужен relogin)
sudo usermod -aG adm deploy
ls -l /var/log/journal | head

Включение отладочных сообщений

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

# временно повысить детализацию службы
sudo systemctl edit nginx
# в открывшемся файле:
# [Service]
# Environment=UNIT_LOG_LEVEL=debug
sudo systemctl restart nginx
# собрать и вернуть обратно
journalctl -u nginx --since "15 min ago" | wc -l
sudo systemctl revert nginx 2>/dev/null

Для ядра уровень задаётся параметром загрузки loglevel=7. После эксперимента верните значение по умолчанию, иначе журнал заполнится мелочью.

Передача событий наружу

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

# простой вариант: доставка в удалённый syslog
# /etc/systemd/journald.conf
# ForwardToSyslog=yes
grep -E "ForwardTo|Remote" /etc/systemd/journald.conf
sudo systemctl restart systemd-journald
# проверить, что события уходят
logger "тестовое событие $(date)"
# на принимающей стороне
grep "тестовое событие" /var/log/syslog | tail -3

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

Итог

journalctl закрывает все задачи чтения логов: время, сервис, важность, поиск, JSON и поток событий. Освойте -b, -u, -p, --since и -f — этого достаточно для 90% разборов. Следите за размером журналов и отправляйте копии наружу сервера, чтобы при инциденте сохранить улики.