Логи сервисов: journald и journalctl

Куда уходят логи сервиса

Раньше каждый сервис писал в свой файл в /var/log/, и приходилось помнить десяток путей. На systemd-хосте логи всех сервисов собирает один компонент — journald. Он принимает stdout и stderr каждого юнита, добавляет метаданные (какой юнит, когда, какой приоритет) и складывает в общий бинарный журнал.

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

journalctl: базовое чтение

journalctl                 # весь журнал, от старого к новому
journalctl -e              # сразу в конец (свежие записи)
journalctl -n 50           # последние 50 строк
journalctl -r              # в обратном порядке, новые сверху

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

Фильтр по юниту

journalctl -u myapp              # только логи юнита myapp
journalctl -u myapp -u nginx     # сразу несколько юнитов

-u (unit) — главный фильтр в работе. Связывает journald напрямую с предыдущим уроком: тот же юнит, которым управляет systemctl. Вывод выглядит так:

$ journalctl -u myapp -n 3
июн 18 10:14:01 web-01 myapp[812]: listening on :8080
июн 18 10:14:02 web-01 myapp[812]: ERROR payment failed: gateway timeout
июн 18 10:14:05 web-01 myapp[812]: retry scheduled

Каждая строка — это дата, хост, имя юнита с PID и само сообщение.

Удобнее всего смотреть лог в реальном времени, как tail -f:

journalctl -u myapp -f

-f (follow) держит вывод открытым и дописывает новые строки по мере их появления. Так смотрят за сервисом во время деплоя или отладки.

Фильтр по времени

journalctl -u myapp --since "2026-06-18 09:00"
journalctl -u myapp --since "1 hour ago"
journalctl --since today
journalctl --since "10 min ago" --until "5 min ago"

--since и --until принимают и абсолютное время, и относительное (yesterday, 2 hours ago). Это сразу отсекает шум: смотришь окно вокруг инцидента, а не весь журнал.

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

У каждой записи есть уровень важности (как в syslog). Фильтр -p показывает записи не ниже указанного:

journalctl -u myapp -p err     # только ошибки и критичнее
journalctl -p warning          # warning и выше по всем юнитам

Уровни от тихих к громким: debug, info, notice, warning, err, crit, alert, emerg. На разборе аварии обычно начинают с -p err, чтобы сразу увидеть ошибки.

Размер журнала

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

journalctl --disk-usage            # сколько места занято
journalctl --vacuum-time=7d        # удалить записи старше 7 дней
journalctl --vacuum-size=500M      # оставить не больше 500 МБ

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

Что важно запомнить

journald собирает stdout/stderr всех юнитов в один журнал с метаданными; читается он только через journalctl.

Главные фильтры: -u по юниту, --since/--until по времени, -p по приоритету, -f для слежения в реальном времени. Их комбинируют.

Журнал ограничен по размеру и чистится сам; постоянное хранение даёт каталог /var/log/journal/.

Дальше логи встретятся в треке про наблюдаемость: уровни логирования, структурные логи и сбор в централизованные системы.