Архитектура системного бинарного журнала systemd-journald

Служба systemd-journald является ядром сбора системных событий, сообщений ядра (kmsg), логов демонов (stdout/stderr) и аудита безопасности в современных дистрибутивах Linux. Журнал сохраняется в структурированном бинарном формате с поддержкой индексации по полям и криптографической верификации (FSS). При некорректной базовой настройке journald администраторы сталкиваются с двумя крайностями:

• Потеря истории после перезагрузки: Журнал работает в режиме Storage=volatile и сохраняется только в оперативной памяти (/run/log/journal), стирая все данные при падении сервера;
• Бесконтрольное переполнение диска: Журнал занимает 10%–20% корневого раздела, вытесняя свободное место и приводя к сбоям СУБД;
• Journal corruption / Corrupt journal entry: Повреждение бинарных индексов логов при некорректном завершении работы.

Бизнес-риски

Невозможность ретроспективного расследования инцидентов информационной безопасности и аварий, падение приложений из-за 100% переполнения раздела /var/log.

Параметры директивы Storage в journald.conf

Регламент оптимизации, ротации и очистки journald

Сценарий 1: Включение персистентного хранения и настройка квот диска

Сконфигурируйте файл /etc/systemd/journald.conf:

# 1. Создайте каталог для постоянного хранения на диске:
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

# 2. Настройка параметров хранения и ротации:
sudo nano /etc/systemd/journald.conf

# Установите следующие директивы в секции [Journal]:
[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G          # Максимальный суммарный размер всех файлов журнала на диске
SystemKeepFree=5G        # Сколько свободного места ВСЕГДА оставлять на диске
SystemMaxFileSize=100M   # Максимальный размер одного сегмента файла журнала
MaxRetentionSec=1month   # Хранить логи не дольше 1 месяца
RateLimitIntervalSec=30s # Ограничение флуда сообщениями (Rate Limiting)
RateLimitBurst=10000

# 3. Перезапустите службу journald для применения настроек:
sudo systemctl restart systemd-journald

Сценарий 2: Экстренная очистка и вакуумирование старых логов (Vacuuming)

Если диск уже переполнен, очистите старые журналы без остановки системы:

# 1. Проверка текущего объема, занятого логами на диске:
journalctl --disk-usage

# 2. Вакуумирование: оставить журналы только за последние 3 дня:
sudo journalctl --vacuum-time=3d

# 3. Вакуумирование: уменьшить суммарный размер логов до 500 МБ:
sudo journalctl --vacuum-size=500M

# 4. Проверка целостности бинарных файлов журнала:
sudo journalctl --verify

Сценарий 3: Эффективная выборка данных через journalctl

# Вывод логов конкретного юнита за последний час с форматированием JSON:
journalctl -u nginx.service --since "1 hour ago" --no-pager

# Мониторинг системных ошибок ядра в реальном времени:
journalctl -k -f -p 3

Типовые ошибки администраторов

• Удаление файлов .journal через rm -rf /var/log/journal/*: Ручное удаление открытых активных файлов журнала нарушает внутренние дескрипторы демона и оставляет занятое место в ОС. Всегда используйте команду journalctl --vacuum-*.
• Отключение Rate Limiting при флудящих сервисах: Если сервис пишет 100 000 ошибок в секунду, отключенный RateLimit приведет к 100% утилизации CPU процессом systemd-journald.