Анализ логов systemd-journald: полное руководство по journalctl

Введение / Зачем это нужно

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

Анализ этих журналов позволяет:

• Быстро диагностировать сбои сервисов и приложений.
• Отслеживать историю событий с точностью до микросекунд.
• Связывать логи из разных источников (ядро, systemd, пользовательские приложения).
• Экономить место за счет сжатия и ротации.

Этот гайд превратит вас из новичка, который знает только journalctl, в уверенного пользователя, способного находить иголку в стоге сена.

Требования / Подготовка

Перед началом убедитесь, что:

1. Система использует systemd (проверьте: pidof systemd). Большинство дистрибутивов с 2015 года.
2. У вас есть права root (или sudo) для доступа ко всем логам. Без прав вы увидите только свои записи.
3. Журнал активен (обычно так). Проверьте: systemctl status systemd-journald.
4. На диске достаточно места для хранения и ротации логов (по умолчанию 10% от раздела /var).

💡 Совет: Настройте размер журнала через /etc/systemd/journald.conf (параметры SystemMaxUse, SystemMaxFileSize), если место ограничено.

Шаг 1: Базовый просмотр и навигация

Первое, что нужно освоить — простое чтение журнала.

# Показать все записи (от старых к новым)
journalctl

# Показать последние 50 записей (аналог tail)
journalctl -n 50

# Постраничный просмотр (автоматически при большом выводе)
journalctl | less

# В less: пробел — вперёд, b — назад, / — поиск, q — выход

Что вы видите: Каждая строка содержит временную метку, хост, источник (например, sshd[1234]) и сообщение. По умолчанию вывод отсортирован по времени (старые -> новые).

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

Это самый частый кейс: «что случилось час/день/неделю назад?». Используйте флаги --since и --until.

# Логи за последний час
journalctl --since "1 hour ago"

# Логи за сегодня (с 00:00)
journalctl --since today

# Логи за конкретную дату и время
journalctl --since "2024-01-15 09:00:00" --until "2024-01-15 10:00:00"

# Логи за вчера
journalctl --since yesterday

# Комбинируйте: с 1 февраля по сейчас
journalctl --since "2024-02-01"

Форматы времени: YYYY-MM-DD HH:MM:SS, относительные (5 min ago, 2 hours ago), ключевые слова (today, yesterday).

Шаг 3: Фильтрация по сервисам и источникам

Ищете, почему упал nginx или что сделал sudo? Фильтруйте по unit-файлам, PID или приоритету.

# Логи конкретного systemd-сервиса
journalctl -u nginx.service

# Логи по PID процесса
journalctl _PID=1234

# Логи по приоритету (err, warning, info, debug)
journalctl -p err    # только ошибки
journalctl -p warning..err  # от warning до err (включительно)

# Логи от конкретного исполняемого файла
journalctl /usr/bin/ssh

# Логи с определённым идентификатором (например, kernel)
journalctl -k  # то же, что journalctl _TRANSPORT=kernel

Комбинируйте фильтры:

# Ошибки nginx за последние 2 часа
journalctl -u nginx.service -p err --since "2 hours ago"

# Логи ядра за последний перезагруз
journalctl -k -b -1

Шаг 4: Мониторинг в реальном времени

Для отладки «на лету» используйте режим слежения.

# Следить за новыми записями (как tail -f)
journalctl -f

# Следить за новыми записями конкретного сервиса
journalctl -u docker.service -f

# Следить с фильтром по приоритету (только ошибки)
journalctl -f -p err

Горячие клавиши: Ctrl+C — выход. Ctrl+Z — приостановить (затем fg для возобновления).

Шаг 5: Углубленный анализ и экспорт

Когда нужно сохранить логи или искать сложные паттерны.

# Экспорт всего журнала в текстовый файл (без постраничного вывода)
journalctl --no-pager > full_journal.txt

# Экспорт с фильтрацией (только ошибки ssh за неделю)
journalctl -u sshd.service -p err --since "1 week ago" --no-pager > ssh_errors.txt

# Поиск по тексту в логах (игнорируя регистр)
journalctl | grep -i "timeout"

# Показать поля записи (для отладки фильтров)
journalctl -o verbose -n 1  # подробный вывод одной записи

# Показать только сообщения (без метаданных)
journalctl --output=cat -n 20

Форматы вывода (-o):

• short (по умолчанию) — краткий.
• verbose — все поля, включая _PID, _UID, _GID.
• json / json-pretty — для машинной обработки.
• export — бинарный формат для systemd-journal-remote.

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

Со временем журнал может занять гигабайты. Управляйте ротацией и очищайте вручную.

# Проверить текущее использование диска journald
journalctl --disk-usage

# Принудительно ротировать журналы (создать новый файл)
journalctl --rotate

# Очистить журналы (удалить все старые записи)
journalctl --vacuum-time=1d    # оставить только за последний день
journalctl --vacuum-size=100M  # оставить не более 100 МБ
journalctl --vacuum-files=3    # оставить 3 самых свежих файла

# Просмотр конфигурации journald
cat /etc/systemd/journald.conf

⚠️ Важно: Очистка безвозвратно удаляет данные. Делайте резервные копии (journalctl --rotate && journalctl > backup.log) перед вакуумом в production.

Проверка результата

Вы успешно освоили анализ, если можете:

1. Найти последние ошибки сервиса за указанный период:

   journalctl -u ваш_сервис.service -p err --since "2 hours ago"
   

2. Экспортировать логи для отправки разработчику:

   journalctl --since "yesterday" --no-pager > logs_for_dev.txt
   

3. Отследить событие в реальном времени при перезапуске сервиса:

   journalctl -u ваш_сервис.service -f
   

4. Оценить использование диска и при необходимости очистить старые записи.

Возможные проблемы

Дополнительный ресурс: Полная документация — man journalctl, man journald.conf.