Як виправити переповнений журнал 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:00 і застосовує зберігання як за часом, так і за розміром за один прохід.

Єдине, що таймер не виявить: пошкоджені файли журналу. Після некоректного вимкнення 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.
• Передавайте журнали на зовнішні сховища для довгострокового зберігання.

Плани VPS та виділених серверів FDC забезпечують дисковий ввід-вивід та обсяг пам'яті, необхідні для робочих навантажень виробничих журналів.