Как исправить переполненный журнал systemd

Журнал systemd хранит все сообщения журнала, которые генерирует ваш сервер, и на VPS с небольшим корневым разделом он может незаметно занять все доступное дисковое пространство. Когда это происходит, службы не запускаются, запись данных приостанавливается, и вы теряете именно ту диагностическую информацию, которая нужна вам, чтобы понять, что пошло не так. В этом руководстве рассказывается, как диагностировать проблему, немедленно освободить место и настроить journald, чтобы это не повторилось.

Диагностика проблемы

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

journalctl --disk-usage

Здесь отображается совокупный размер всех активных и заархивированных файлов журнала. Сравните это значение с доступным дисковым пространством с помощью df -h. На корневом разделе объемом 20 ГБ даже 2 ГБ журналов составляют более 10% от общего объема диска, чего достаточно, чтобы вызвать проблемы.

Затем выясните, какие службы генерируют больше всего шума. Эта однострочная команда ранжирует 10 основных источников журналов за последние 24 часа:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Отфильтруйте ошибки с помощью journalctl -p err -b , чтобы увидеть, не застрял ли какой-то сервис в цикле сбоев и не переполняет ли журнал. Вы также можете проверить, не ограничивает ли journald скорость каких-либо сервисов:

journalctl -u systemd-journald | grep -i "suppressed"

Сообщения о подавлении означают, что служба превысила пороговое значение по умолчанию в 10 000 записей за 30 секунд. Это и есть ваш виновник.

Некоторые проблемы особенно часто встречаются на VPS-инстансах. Если Storage=auto задан и /var/log/journal/ существует, journald использует постоянное хранилище с ограничением по размеру по умолчанию примерно в 4 ГБ. На небольшом корневом разделе оно быстро заполняется. Некорректные выключения также могут оставлять поврежденные файлы журнала с суффиксом .journal~ . Эти файлы не ротируются нормально и продолжают занимать место

Безопасная очистка журналов

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

journalctl --rotate

Затем очистите архивированные журналы. Вы можете выбрать критерии по дате, размеру или количеству файлов:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

Первый вариант удаляет журналы, старше 24 часов. Второй уменьшает общий размер журнала до 100 МБ. Третий сохраняет только пять самых последних архивированных файлов. Выберите вариант, который подходит для вашей ситуации.

Если диск полностью заполнен и команды journalctl не отвечают, возможно, вам придется удалить файлы журнала вручную:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

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

sudo systemctl restart systemd-journald
journalctl --disk-usage

Настройка ограничений размера Journald

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

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

Ключевые директивы:

Установка обоих SystemMaxUse и SystemKeepFree обеспечивает двойную защиту: размер журналов ограничивается фиксированным значением, и у системы всегда остается запас места, независимо от того, что еще находится на диске.

Постоянное и энергозависимое хранение

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

sudo mkdir -p /var/log/journal

Альтернативный вариант, Storage=volatile, хранит журналы в ОЗУ в /run/log/journal/. Журналы исчезают при перезагрузке. Это имеет смысл для кратковременных контейнеров или серверов, которые пересылают все журналы во внешнюю систему.

Отключение сжатия на серверах с высокой нагрузкой

По умолчанию journald сжимает объекты данных размером более 512 байт. На серверах с высокой пропускной способностью журналов это увеличивает нагрузку на процессор. Установите Compress=no , если вы пересылаете журналы во внешнюю систему и не нуждаетесь в минимизации локального хранилища. Также установите ForwardToConsole=no в производственной среде. Пересылка консоли происходит синхронно, и зависшая виртуальная последовательная консоль может полностью заблокировать демон journald.

После любого изменения конфигурации перезапустите службу:

sudo systemctl restart systemd-journald

Автоматизация обслуживания журналов

Ручная очистка не масштабируется. Создайте таймер systemd для очистки журналов по расписанию. Настройте сервисную единицу в /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

Затем создайте соответствующий таймер в /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Включите его с помощью sudo systemctl enable --now journal-vacuum.timer. Таймер запускается каждое воскресенье в 2 часа ночи и применяет хранение как по времени, так и по размеру за один проход.

Единственное, что таймер не уловит: поврежденные файлы журнала. После некорректного завершения работы journald помещает поврежденные файлы в карантин, добавляя ~ к имени файла. Эти .journal~ файлы по-прежнему учитываются при подсчете использования дискового пространства, но не будут автоматически очищены. Периодически проверяйте наличие старых файлов и удаляйте их:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Перенаправление журналов на внешний сервер

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

ForwardToSyslog=yes

Для структурированных журналов с полными метаданными (PID, UID, имена модулей) используйте systemd-journal-remote для отправки записей в формате JSON на платформу управления журналами. Внешнее хранилище журналов также защищает ваш аудиторский след в случае сбоя локального диска или взлома сервера

Заключение

Полный журнал systemd легко исправить и предотвратить. Основные шаги:

• Проверьте использование с помощью journalctl --disk-usage и определите ресурсоемкие службы.
• Немедленно освободить место с помощью journalctl --rotate затем --vacuum-size или --vacuum-time.
• Установите явные ограничения на размер в файле переопределения journald.conf.
• Автоматизируйте очистку с помощью таймера systemd.
• Перенаправляйте журналы на внешний сервер для долгосрочного хранения.

Тарифные планы FDC на VPS и выделенные серверы обеспечивают дисковый ввод-вывод и хранилище, необходимые для рабочих нагрузок производственных журналов.