Журнал исчез после reboot: настраиваем хранение и бюджет journald

После аварийной перезагрузки в journalctl видна только текущая загрузка. Команда ищет сбой вчерашнего вечера, но локальная история не сохранилась. Чтобы это не повторялось, нужно проверить место хранения journald и срок, который реально помещается в выделенный бюджет.

Установить фактический режим

systemd-analyze cat-config systemd/journald.conf
journalctl --list-boots
journalctl --disk-usage
ls -ld /run/log/journal /var/log/journal

Storage=volatile хранит данные под /run/log/journal; Storage=persistent предпочитает /var/log/journal с временным использованием runtime во время ранней загрузки или недоступности диска. auto зависит от наличия постоянного каталога. Значения по умолчанию зависят от сборки и дистрибутива, поэтому выводите эффективную конфигурацию вместе с drop-in.

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

Задать управляемый бюджет

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14day

Это пример drop-in для отдельного сервера, а не универсальные значения. SystemMaxUse ограничивает размер постоянного журнала, SystemKeepFree учитывает свободное место, MaxRetentionSec задаёт предельный возраст. Если объём заполнится раньше четырнадцати дней, старые события уйдут раньше. Возрастной предел не является гарантией минимального retention.

Для runtime-хранения существуют отдельные RuntimeMaxUse и RuntimeKeepFree. Полный смысл параметров разобран в journald.conf. Учитывайте активные и архивные файлы: поведение очистки не сводится к удалению любых байтов ровно при пересечении указанного числа.

Проверить скорость поступления

Если за сутки возникает примерно 600 МиБ журнала, бюджет 1 ГиБ не сохранит две недели при сопоставимой сжимаемости. Измеряйте расход на обычной нагрузке и отдельно во время всплеска ошибок. Бесконечное повторение одной ошибки способно вытеснить полезную историю, даже если обычный день был тихим.

RateLimitIntervalSec и RateLimitBurst регулируют ограничение потока, а у службы могут быть собственные настройки. Снижение потока защищает ресурс, но часть сообщений будет отброшена. Поэтому одновременно исправляйте шумный источник и сохраняйте значимые события в подходящей системе наблюдения.

Подтвердить постоянное хранение

После применения конфигурации по процедуре дистрибутива проверьте журнал службы journald. journalctl --flush переводит доступные runtime-данные в постоянное хранение при подходящих условиях; это не команда восстановления старых загрузок. Затем на стенде создайте узнаваемое тестовое событие, выполните согласованную перезагрузку и найдите его в предыдущем boot.

Не используйте vacuum как первую проверку — это удаление истории. Для изменения политики сначала сохраните нужный интервал расследования. Проверяйте также доступ оператора к системному журналу: persistent-файлы могут существовать, но быть ему невидимы.

Практический результат — подтверждённая история через reboot и измеренный срок хранения при реальном потоке. Посмотрите программу Linux и Bash для DevOps-инженеров: работа с журналами и дисками поможет связать хранение диагностических данных с ресурсами учебного сервера.

Ещё по теме

• Посчитать ошибки по сервисам в awk: агрегируем журнал за один проход
• Пустая колонка TSV сдвинула значение: выбираем разделитель awk