Как читать и анализировать логи systemd через journalctl: фильтры, хранение, ротация и централизованный сбор

journalctl читает журнал systemd-journald. Для первичной диагностики сбоя обычно достаточно отфильтровать записи по unit, текущей загрузке, времени и приоритету. Безопасные команды: journalctl -u nginx.service -b, journalctl -u nginx.service --since '30 min ago', journalctl -p warning..alert -b. Имя unit подтверждайте через systemctl status <служба>. journalctl -xe показывает контекст, но не заменяет точную фильтрацию.

Что проверить в journalctl при сбое сервиса

Определите unit и границы инцидента

Проверьте имя службы: systemctl status nginx.service, systemctl list-units --type=service. Зафиксируйте время начала инцидента, хост и затронутую службу. Короткий временной интервал снижает шум в журнале.

Безопасный стартовый набор команд

journalctl -u <unit> -b показывает сообщения unit в текущей загрузке. journalctl -u <unit> --since 'YYYY-MM-DD HH:MM:SS' --until 'YYYY-MM-DD HH:MM:SS' ограничивает период. journalctl -u <unit> -p err..alert выводит только ошибки и критические события. journalctl -f -u <unit> следует за новыми записями, прерывается Ctrl+C.

Как устроены journalctl и systemd-journald

Какие поля журнал использует для фильтрации

Записи содержат поля с префиксом _ и пользовательские поля. Практически важны: _SYSTEMD_UNIT (имя unit), _PID (идентификатор процесса), _UID (идентификатор пользователя), PRIORITY (уровень важности), _BOOT_ID (идентификатор загрузки). Подробный формат journalctl -o verbose показывает все поля записи.

Почему журналы могут не переживать перезагрузку

Volatile-хранилище в /run/log/journal теряет записи при перезагрузке. Persistent-хранилище в /var/log/journal сохраняет их. Параметр Storage в journald.conf определяет целевое размещение. Поведение зависит от версии systemd, сверяйтесь с man journald.conf и journalctl --disk-usage.

Фильтры journalctl по сервису, времени, приоритету, PID, UID и загрузке

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

Таблица 1. Основные фильтры journalctl

Как сочетать условия и не потерять важные сообщения

Пример: ошибки nginx за последние 30 минут: journalctl -u nginx.service --since '30 min ago' -p err..alert. События сервиса в предыдущей загрузке: journalctl -u nginx.service -b -1. Сообщения процесса в период перезапуска: сначала найдите PID в текущих логах, затем journalctl _PID=1234 --since ... --until .... Несколько полей сужают выборку, поэтому начинайте с unit и времени, затем добавляйте PID, UID или приоритет.

Вывод, контекст и экспорт для анализа

-o short-iso удобен для сопоставления времени между системами. -o verbose показывает все поля. -o json-pretty выводит структуру JSON. -o export создает бинарный дамп для передачи. Экспорт журналов может содержать IP-адреса, имена хостов, пути, токены или персональные данные.

Постоянное хранение логов: настройка systemd-journald

Когда выбирать persistent, volatile или auto

Storage=persistent сохраняет журналы в /var/log/journal. Storage=volatile использует /run/log/journal, данные теряются при перезагрузке. Storage=auto выбирает persistent, если /var/log/journal существует. Для серверов, где нужны журналы между перезагрузками, выбирайте persistent. Volatile подходит для временных или чувствительных к записи носителей.

Параметры journald.conf и их назначение

Вторая таблица содержит ключевые параметры. Доступность и семантика зависят от версии systemd, сверяйтесь с man journald.conf.

Таблица 2. Параметры journald.conf

Пример конфигурации с лимитами и проверка применения

Создайте drop-in файл /etc/systemd/journald.conf.d/60-storage.conf с содержимым:

[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=5G
SystemMaxFileSize=128M

Проверьте свободное место: df -h /var/log. Создайте каталог: sudo mkdir -p /var/log/journal. Перезапустите службу: sudo systemctl restart systemd-journald. Проверьте статус: systemctl status systemd-journald. Проверьте использование: journalctl --disk-usage.

Ротация логов journald и безопасное освобождение диска

Как проверить размер, возраст и структуру журналов

journalctl --disk-usage показывает объем. journalctl --list-boots выводит список загрузок. sudo journalctl --verify проверяет целостность файлов, но не исправляет ошибки. df -h показывает свободное место. Оценивайте постоянный и runtime-журнал отдельно.

Команды vacuum: когда применять и какие данные будут удалены

Перед vacuum выполните ротацию: journalctl --rotate. Примеры: sudo journalctl --vacuum-size=1G, sudo journalctl --vacuum-time=14d, sudo journalctl --vacuum-files=10. Vacuum удаляет только архивные файлы, поэтому --rotate делает текущий файл кандидатом на очистку. Выполняйте после фиксации или экспорта нужных данных. Не используйте vacuum как регулярную замену лимитам journald.conf.

Экспорт журналов и централизованный сбор systemd-journal-remote

Экспорт выбранного фрагмента журнала

Текстовый экспорт: journalctl -u nginx.service --since '2025-01-15 10:00' --until '2025-01-15 11:00' -o short-iso > nginx-incident.log. Бинарный экспорт: journalctl -u nginx.service -b -o export > nginx-current-boot.export. Текстовый вывод удобен для чтения, export подходит для передачи в экосистеме journal. Проверяйте содержимое и защищайте файл перед отправкой.

Базовая схема центрального приема журналов

systemd-journal-upload на клиентах отправляет журнал по HTTPS, systemd-journal-remote на центральном узле принимает и сохраняет записи, journalctl читает принятые журналы. Последовательность: подготовьте TLS-сертификаты, ограничьте сетевой доступ, настройте URL приемника на клиенте, включите и проверьте службы, отправьте тестовое событие. Имена unit, пути конфигурации и опции подтверждайте в документации дистрибутива и man-страницах.

Безопасность, доступ и срок хранения на центральном узле

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

Типовые проблемы systemd-journald и способы устранения

Как отличить сбой journald от проблемы приложения

Проверьте systemctl status systemd-journald, journalctl -u systemd-journald -b и сравните с журналом целевого unit. Отсутствие ошибок приложения не доказывает его исправность: приложение может писать в отдельный файл, контейнерный runtime или удаленную систему логирования.

Третья таблица содержит типовые проблемы и способы устранения.

Таблица 3. Типовые проблемы systemd-journald

Чек-лист диагностики: от симптома к сохраненному журналу

1. Зафиксируйте время, хост и сервис.
2. Проверьте systemctl status <service>.
3. Просмотрите записи unit в текущей и предыдущей загрузке: journalctl -u <unit> -b, journalctl -u <unit> -b -1.
4. Ограничьте период и приоритет: journalctl -u <unit> --since ... --until ... -p warning..alert.
5. Проверьте PID, UID и связанные units при необходимости.
6. Оцените journalctl --disk-usage и свободное место.
7. Экспортируйте нужный фрагмент до очистки.
8. Проверьте persistent-хранение и лимиты.
9. При необходимости проверьте доставку на центральный сервер.

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