Debian 13: Journald з’їв ваш диск — обмежте логи, не втрачаючи важливого

Швидкий план діагностики

Це послідовність «дзвонить pager, диск 98%, і додаток видає дивні помилки». Ви хочете сигнал за менше п’яти хвилин. Робіть ці кроки в цьому порядку.

Перш за все: підтвердіть, куди поділося місце

• Перевірте файлову систему, яка заповнена, і чи це шлях журналу (зазвичай /var або корінь).
• Заміряйте /var/log/journal та /run/log/journal.
• Перевірте відомості journald про використання місця.

По-друге: визначте, чи це шторм логів чи питання зберігання

• Шукайте повідомлення про обмеження швидкості, повторні збої юнітів або дуже балакучий сервіс.
• Перевірте швидкість інґесту: підрахунок за «останні 5 хвилин» по юнітах.
• Підтвердіть, чи логи зберігаються на диску і які ліміти налаштовані.

По-третє: зупиніть витік безпечно

• Виконайте vacuum за розміром або часом (не випадкове видалення), і переконайтеся, що не видаляєте єдину копію потрібних логів.
• Застосуйте обмеження в journald.conf і перезапустіть journald.
• Виправте балакучий сервіс. Інакше ви просто вимітаєте воду мітлою.

Жарт #1: Логи як блискітки — чудово для творчості, катастрофа в продукції, і ви знайдете їх у місцях, де ніколи не мали б бути.

Що фактично робить journald з диском

systemd-journald збирає логи з ядра, сервісів і всього, що пише в stdout/stderr під systemd. Він зберігає їх у бінарному форматі журналу. Це дає індексацію, структуровані поля і швидкий фільтр. Але це також дає можливість заповнювати диск зі швидкістю «хтось розгорнув debug-логування на гарячому шляху».

Постійне проти тимчасового: тихий роздоріжжя

journald може зберігати логи у пам’яті-вузькому runtime-сховищі (/run/log/journal) або на диску (/var/log/journal). На багатьох серверах бажано мати постійні логи, бо перезавантаження трапляються — іноді навмисно. Але постійне зберігання означає, що потрібно ставити обмеження й політику зберігання, бо диск скінченний, а логи — амбітні.

Чому «диск повний» від логів ламає несуміжні речі

Коли файлову систему, що містить /var, заповнено, journald — не єдине, що перестає писати. Ви можете бачити невдалі інсталяції пакетів, SSH-сесії, які не можуть виділити pty, бази даних, що відмовляються створювати тимчасові файли, і системні сервіси, що падають, бо не можуть писати стан. Перша проблема — «логи виросли». Друга — «всі припускають можливість запису».

Контролі зберігання journald за замовчуванням базуються на відсотках

journald може накладати максимум у абсолютних значеннях (SystemMaxUse=) і тримати буфери вільного місця (SystemKeepFree=). За замовчуванням значення можуть бути надто поблажливими для малих томів, особливо на ВМ з вузькими кореневими дисками.

Ротація — не проблема; проблема — зберігання

Люди думають, що «обертання логів» вирішує це. journald вже внутрішньо ротує. Вибухи диска відбуваються коли політика зберігання фактично «зберігати все до дуже великого ліміту, про який ви не підозрювали», або коли швидкість логів настільки велика, що навіть розумний ліміт достигається занадто швидко — викликаючи хрускіт і втрату найновіших або найстаріших повідомлень залежно від налаштувань і тиску.

Цікаві факти та контекст (щоб ви не воювали з хибною проблемою)

• Факт 1: journald зберігає логи в бінарному форматі з індексованими полями, тому journalctl _SYSTEMD_UNIT=foo.service швидкий порівняно з grep по текстових файлах.
• Факт 2: Постійне збереження журналу вимагає наявності /var/log/journal; якщо його немає, journald зазвичай працює в runtime-режимі під /run.
• Факт 3: Формат журналу підтримує механізми цілісності (наприклад, sealing), які покликані виявляти фальсифікації, але вони не замінюють централізоване логування.
• Факт 4: syslog передує journald на десятиліття і зростав навколо додавання текстових файлів та віддаленого форвардингу; journald з’явився з припущенням про багаті метадані та юніт-орієнтовані системи.
• Факт 5: Ядро Linux може викидати потоки повідомлень, якщо драйвер або файлова система починають працювати неправильно; кільце ядра та journald можуть стати небажаними спільниками.
• Факт 6: На завантажених системах саме логування стає функцією продуктивності — або багом продуктивності — бо кожен рядок логу це IO, CPU та конкуренція десь.
• Факт 7: Платформи контейнерів популяризували «логувати в stdout», що при systemd-хостах потрапляє прямо в journald, якщо ви не перенаправите інакше.
• Факт 8: Обмеження на відсоток (наприклад, «використовувати до 10% файлової системи») поводяться дуже по-різному на кореневому томі 20GB порівняно з логовим томом 2TB, і значення за замовчуванням не знають ваших намірів.

Цитата, бо вона досі найкраще керівне обмеження в операціях: Надія — це не стратегія. — перефразована ідея, часто приписувана лідерам в інженерії та операціях.

Практичні завдання: команди, значення виводу, рішення

Це не лабораторні вправи. Це те, що ви робите, коли диск повний або ось-ось буде. Кожне завдання включає: команду, що означає її вивід, і яке рішення потрібно прийняти далі.

Завдання 1: Визначте, яка файловая система насправді переповнена

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/vda1      ext4    30G   29G  200M 100% /
tmpfs          tmpfs  3.1G  1.2M  3.1G   1% /run

Що це означає: Корінь заповнений; persistent-journal ймовірно живе під /var, який тут на /. Ваші записи по всій системі не виконуються.

Рішення: Перейдіть негайно до вимірювання директорій журналу та vacuum. Також заплануйте довгостроковий ліміт, інакше це повториться.

Завдання 2: Заміряйте розміри директорій журналу

cr0x@server:~$ sudo du -sh /var/log/journal /run/log/journal 2>/dev/null
18G	/var/log/journal
24M	/run/log/journal

Що це означає: Persistent journal — головний «сосун». Runtime-journal малий.

Рішення: Виконайте vacuum persistent journal; потім застосуйте обмеження в конфігурації.

Завдання 3: Запитайте у journald, скільки місця він думає, що використовує

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 18.1G in the file system.

Що це означає: Це підтверджує, що облік journald співпадає з тим, що ви бачили в du. Якщо ні — можливо, у вас відкриті, але видалені файли або інші шляхи логів.

Рішення: Якщо це число велике і швидко зростає, вам потрібні й обмеження зберігання, і контроль швидкості/обсягу на джерелі.

Завдання 4: Подивіться, як налаштований journald (ефективні значення)

cr0x@server:~$ sudo systemd-analyze cat-config systemd/journald.conf
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
MaxRetentionSec=1month
RateLimitIntervalSec=30s
RateLimitBurst=10000

# /usr/lib/systemd/journald.conf
[Journal]
#Storage=auto
#SystemMaxUse=
#SystemKeepFree=

Що це означає: Ви бачите, що встановлено в /etc порівняно з дефолтами. Якщо у вас немає явних обмежень, ви довіряєте дефолтам під вашу конфігурацію диска. Це парі, яке зазвичай програють.

Рішення: Покладіть явні ліміти в /etc/systemd/journald.conf (або drop-in), підігнані під ваш диск і потреби відповідності.

Завдання 5: Підтвердіть, що journald використовує persistent-сховище і що шлях існує

cr0x@server:~$ sudo ls -ld /var/log/journal
drwxr-sr-x+ 3 root systemd-journal 4096 Dec 28 08:11 /var/log/journal

Що це означає: Директорія існує з очікуваною групою. Добре. Якби її не було, journald міг би працювати в runtime-режимі і ви б втратили логи після перезавантаження.

Рішення: Якщо вам потрібна постійність, переконайтеся, що /var/log/journal існує і система в групі systemd-journal, де це потрібно.

Завдання 6: Знайдіть найгучніший юніт за останні 5 хвилин

cr0x@server:~$ sudo journalctl --since "5 min ago" --output short-unix | awk '{print $6}' | sort | uniq -c | sort -nr | head
  8421 myapp.service:
  2103 kernel:
   611 sshd[1023]:
   222 systemd[1]:

Що це означає: myapp.service спамить. Ядро теж балакуче, але вторинно.

Рішення: Виправте рівень логування або баг у застосунку спочатку; потім підлаштуйте зберігання journald як страховку, а не як основний контроль.

Завдання 7: Перевірте зміст спаму (не вгадай)

cr0x@server:~$ sudo journalctl -u myapp.service --since "15 min ago" -n 20
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1234
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1235
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1236

Що це означає: Це шум рівня debug у продакшні. Це не «просто логи»; це симптом зміни або неправильної конфігурації.

Рішення: Відкотіть конфіг, зробіть хотфикс рівня логування або додайте семплування. Не «чистіть сильніше».

Завдання 8: Перевірте, чи journald обмежує швидкість (і втрачає повідомлення)

cr0x@server:~$ sudo journalctl -u systemd-journald --since "1 hour ago" | tail -n 20
Dec 28 08:22:12 server systemd-journald[342]: Suppressed 15432 messages from /system.slice/myapp.service
Dec 28 08:22:42 server systemd-journald[342]: Suppressed 18201 messages from /system.slice/myapp.service

Що це означає: journald вже відкидає логи через обмеження швидкості. Ваша проблема з диском і проблема спостережуваності відбуваються разом.

Рішення: Розглядайте це як інцидент: зменшіть обсяг логів у джерелі. Подумайте про окремий конвеєр для логів великого обсягу (метрики, трейси або семпльовані логи).

Завдання 9: Безпечно виконайте vacuum за розміром (найшвидший «звільнити місце» крок)

cr0x@server:~$ sudo journalctl --vacuum-size=2G
Vacuuming done, freed 16.1G of archived journals from /var/log/journal.

Що це означає: Це негайно накладає кап на існуючі дані. Видаляє старі архіви, поки використання не буде близько 2G.

Рішення: Якщо система вогні, зробіть це зараз. Потім реалізуйте конфігурацію, щоб не повторювати вручну.

Завдання 10: Vacuum за часом (корисно для політик відповідності)

cr0x@server:~$ sudo journalctl --vacuum-time=14d
Vacuuming done, freed 6.3G of archived journals from /var/log/journal.

Що це означає: Залишається приблизно останні 14 днів; старі записи видаляються.

Рішення: Використовуйте це, коли політика зберігання часова. Комбінуйте з лімітом розміру, щоб шторм логів не стер весь 14-денний вікно за дві години.

Завдання 11: Перевірте стан диска після vacuum

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   12G   17G  42% /

Що це означає: Ви відійшли від краю. Тепер можна виправляти корінну причину без того, щоб файлова система кричала.

Рішення: Негайно встановіть обмеження journald і виправте балакучий юніт. «Зробимо пізніше» — це як зустріти ту ж проблему наступного тижня.

Завдання 12: Налаштуйте обмеження (drop-in), потім перезапустіть journald

cr0x@server:~$ sudo install -d -m 0755 /etc/systemd/journald.conf.d
cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/00-limits.conf >/dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RuntimeMaxUse=256M
RuntimeKeepFree=64M
MaxRetentionSec=1month
MaxFileSec=1day
RateLimitIntervalSec=30s
RateLimitBurst=5000
EOF
cr0x@server:~$ sudo systemctl restart systemd-journald

Що це означає: Ви встановили явні стелі й буфер «keep free», щоб захистити решту системи. Ви також задали каденс ротації (MaxFileSec) та обмеження швидкості.

Рішення: Налаштуйте ці числа відповідно до розміру диска й потреб інцидент-реагування. Якщо корінь 20–40GB, 2GB журнал зазвичай адекватний. На виділених логових томах можна ставити більше.

Завдання 13: Підтвердіть ефективні налаштування після змін

cr0x@server:~$ sudo systemd-analyze cat-config systemd/journald.conf | sed -n '1,80p'
# /etc/systemd/journald.conf.d/00-limits.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RuntimeMaxUse=256M
RuntimeKeepFree=64M
MaxRetentionSec=1month
MaxFileSec=1day
RateLimitIntervalSec=30s
RateLimitBurst=5000

Що це означає: Ви не довіряєте пам’яті. Ви читаєте фактичний конфіг, який systemd застосує.

Рішення: Якщо бачите кілька конфліктних drop-in, об’єднайте їх. Розкиданість конфігів — це як ліміти перестають працювати мовчки.

Завдання 14: Визначте видалені, але все ще відкриті файли (пастка «df каже повний, du каже ні»)

cr0x@server:~$ sudo lsof +L1 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
systemd-j 342 root   12w  REG  253,0  1048576     0 1234 /var/log/journal/.../system@000000.journal (deleted)

Що це означає: Місце може залишатися «використаним», доки процес не закриє дескриптори, навіть якщо файл видалено.

Рішення: Перезапустіть процес, що тримає файли (часто сам journald), після vacuum або очищення, якщо бачите багато видалених журналів, що тримаються відкритими.

Завдання 15: Переконайтеся, що journald здоровий і не в трясці

cr0x@server:~$ systemctl status systemd-journald --no-pager
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Sun 2025-12-28 08:40:12 UTC; 2min ago
       Docs: man:systemd-journald.service(8)
           man:journald.conf(5)

Що це означає: journald працює. Це не гарантує, що він не відкидає повідомлень, але це усуває базовий режим «сервіс помер».

Рішення: Якщо journald зациклений на перезапуску, можлива корупція диска або проблеми з правами. Перейдіть до перевірок цілісності файлів і прав доступу.

Завдання 16: Спостерігайте тренд використання диска (дешеве раннє попередження)

cr0x@server:~$ sudo watch -n 2 'journalctl --disk-usage; df -h / | tail -n 1'
Archived and active journals take up 1.9G in the file system.
 /dev/vda1        30G   12G   17G  42% /

Що це означає: Ви можете бачити, чи використання журналу стабільне або стрімко зростає.

Рішення: Якщо після застосування обмежень воно все одно стрімко росте, ви бачите churn (постійне видалення і перезапис), що може знизити продуктивність і все ще втратити важливі логи. Виправляйте джерело логів.

Обмеження логів без жалю: зберігання, ліміти та розділення

Виберіть політику зберігання так само, як вибираєте бекапи: на підставі відновлення, а не відчуттів

Рetention логів — це інженерна вимога в одязі відповідності. Ви хочете достатньо логів, щоб відповісти: «Що змінилося?», «Що першим відмовило?» і «Хто/що торкався цієї системи?». Якщо ви не можете відповісти, у вас не спостережуваність — у вас стрічка тривоги.

На типовій Debian-ВМ з кореневим диском 20–50GB, кап журналу в діапазоні 1–4GB — розумний. Якщо потрібно більше, змонтуйте окрему файлову систему для /var/log або принаймні для /var/log/journal. Тримати persistent-journals на кореневому файловому диску — прийнятно, поки не станеться інакше — а воно завжди буває «поки не станеться».

Користуйтеся і часовими, і розмірними лімітами

Тільки часове зберігання провалюється під час штормів логів: ви можете прогорати «14 днів» за один день. Тільки розмірне зберігання провалюється під час спокійних періодів: ви можете утримувати 90 днів ненавмисно, що звучить красиво, поки хтось не запитає, чому все ще зберігаються чутливі debug-логи.

Прагматичне поєднання:

• SystemMaxUse= встановлює верхню межу.
• SystemKeepFree= захищає іншу частину файлової системи від зростання журналу.
• MaxRetentionSec= виражає політику зберігання.
• MaxFileSec= контролює гранулярність ротації, що робить вакуум менш «все або нічого».

Ліміти швидкості не замінюють виправлення шумних сервісів

Rate limiting у journald захищає систему від колапсу. Він також ховає докази, коли вони найбільше потрібні. Якщо ви бачите повідомлення про пригнічення, сприймайте їх як сигнал про невдачу.

Правильний порядок дій:

1. Зменште обсяг логів у джерелі (рівень логів, семплування, виправлення зациклень).
2. Обмежте використання journald, щоб вузол лишався живим.
3. Перешліть потрібні логи в централізовану систему з власними політиками зберігання і контролем доступу.

Відокремте «локальний форензичний буфер» від «підприємницького зберігання»

Локальні журнали чудові для негайної триажі: вони переживають перезавантаження, мають метадані і знаходяться під рукою. Але диск одного вузла — не ваш архів відповідності і не єдине джерело істини.

Якщо вам потрібне довготривале зберігання, пересилайте логи за межі вузла. Чи то rsyslog, опції пересилки journald, чи агент — принцип один: локальний диск — демпфер, а не довготривале сховище.

Бітьтеся свідомо за те, що «важливе»

Важливе — це не «все». Важливе — це:

• Логи автентифікації (спроби входу, sudo, sshd, відмови PAM).
• Зміни привілеїв і перезапуски сервісів.
• Помилки ядра та сховища (тайм-аути I/O, помилки файлової системи).
• Маркери розгортання та зміни конфігурації.
• Помилки застосунків і відмови запитів, але бажано не кожна debug-марка.

Коли ви обмежуєте логи, ви вирішуєте, що можете дозволити собі втратити. Приймайте це рішення свідомо, а не дозволяйте диску вирішувати за вас.

Три корпоративні міні-історії (болісно, у трьох екземплярах)

Міні-історія 1: Інцидент через хибне припущення

Середня компанія мігрувала флот Debian-серверів з «класичного syslog плюс ротація текстових файлів» до systemd-орієнтованого логування. SRE команда оцінила, як швидко можна фільтрувати по юніту і як journald ловив stdout сервісів, які раніше губилися.

Хтось зробив чисте, впевнене припущення: «journald має розумні дефолти; він не заповнить диск». Ніхто не перевірив, що означає «розумний» на їхніх найменших продакшн-ноду. Ці ноди мали скромні кореневі об’єми, бо «вони запускають лише побічні сервіси».

Одного понеділка сервіс почав невпинно спілкуватися з внутрішнім залежністю. Цикл повторних спроб логувався на INFO при кожній спробі, з дампами payload тому що debug-flag залишився після тесту. Сервіс не впав. Він залишився і кричав.

За кілька годин кореневі файлові системи заповнилися. Раптом несуміжні сервіси почали відмовляти: оновлення пакетів, агенти метрик і навіть SSH на кількох машинах. Команда ганялася за «мережевими примарами», бо перші симптоми були «не вдається розгорнути» і «не проходять health checks». Занадто довго не помічали розмір журналу.

Фікс був нудний: явно обмежити журнал і додати буфер «keep free». Виправлення кореневої причини теж було нудним: прибрати дампи payload з дефолтних логів і перевести ретраї в структуровані метрики з семплуванням. Урок був гострий: дефолти — не політика, і «не заповнить диск» — це не властивість, а конфігурація.

Міні-історія 2: Оптимізація, що обернулася проти

Інша організація вирішила бути розумною. Вони запускали багато сервісів на одному класі нод і хотіли зменшити використання диска та IO. Тому вони поставили агресивні обмеження journald: крихітний SystemMaxUse, коротке зберігання і низькі ліміти швидкості. Ідея була «захистити вузол» і «змусити команди користуватися централізованою платформою логування».

Це спрацювало. Використання диска трималося низьким. Вузол вижив під час штормів логів. Всі похвалилися і переключилися.

Потім стався інцидент у продукції: повільна помилка, яка виникала раз у кілька годин і лишала слабкий слід у логах. Під час інциденту система також породила сплеск не пов’язаних шумних логів від флапаючої залежності. Малий локальний буфер journald означав, що релевантні помилки були швидко витіснені; агресивне пригнічення швидкості підтискало сплески; і центральний конвеєр логів, що був в обслуговуванні, мав пропуски.

Вони отримали саме неправильний результат: система пережила, але докази зникли. Постмортем був болісним, бо справа була не «ми не логували». Це було «ми залогували, але спроєктували систему так, щоб вона забула в найгірший момент».

Вони відкотилися до більшого локального буфера на кожному вузлі і стали ставитися до центрального конвеєра як до надійного сховища, а не єдиної точки відмови. Оптимізація, що врятувала диск, тихо підвищила середній час діагностики.

Міні-історія 3: Нудна, але правильна практика, що врятувала

Регульована компанія з репутацією «повільних» мала практику, над якою інженери піджартовували: у кожного класу нод була явна політика journald у системі керування конфігурацією. Вона вказувала ліміти, зберігання і мінімальний буфер вільного місця. Кожна зміна проходила code review. Кожен вузол також транспонував критичні логи за межі хосту.

Під час регресії драйвера від вендора ядро почало викидати попередження зберігання на деяких хостах. Ці попередження спровокували каскад: користувацький сервіс теж почав повторюватися і логувати. Система пережила шторм логів — саме такий, що знищує диски.

Але ноди не впали. journald досягнув своїх капів, тримав буфер вільного місця і продовжував приймати достатньо повідомлень, щоб показати хронологію. Оскільки логи були переслані, команда змогла розібрати послідовність навіть на нодах, що перезавантажилися.

Інцидент усе ще був реальним — апаратні й драйверні проблеми завжди реальні. Але він залишився в межах «збій продуктивності», а не «невзутні хости з відсутніми доказами». Нудна практика не отримує оплесків. Вона забезпечує аптайм.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: Диск повний; /var/log/journal величезний

Корінна причина: Немає явного SystemMaxUse / SystemKeepFree, або ліміти занадто великі для розміру кореневого файлового тому.

Виправлення: Виконайте vacuum негайно, потім встановіть явні ліміти у drop-in і перезапустіть journald. Розгляньте виділену файлову систему для логів.

2) Симптом: Диск повний, але du не показує, куди пішло місце

Корінна причина: Видалені файли все ще тримаються відкритими (поширено після ручних видалень), або ріст у іншому монтуванні.

Виправлення: Використайте lsof +L1, щоб знайти відкриті видалені файли; перезапустіть процес, що тримає файли. Уникайте ручного видалення; користуйтеся journalctl --vacuum-*.

3) Симптом: Відсутні логи під час інциденту

Корінна причина: Пригнічення швидкості відкидає повідомлення, капи журналу занадто малі і швидко витісняють, або логи були лише в runtime і загублені після перезавантаження.

Виправлення: Зменшіть обсяг логів в джерелі; налаштуйте RateLimit*; впевніться, що Storage=persistent і директорія існує; пересилайте критичні логи за межі хоста.

4) Симптом: CPU journald злітає; система пригальмовує під час штормів

Корінна причина: Великий обсяг логів викликає конкуренцію й IO; занадто часті ротації; постійний churn вакуума під жорсткими капами.

Виправлення: Виправте шумний юніт, трохи збільшіть капи, щоб зменшити churn, і тримайте ротацію розумною (MaxFileSec). Розгляньте перенесення журналів на швидший диск або окремий том.

5) Симптом: Після перезавантаження історія журналу зникла

Корінна причина: journald у runtime-режимі (/run), бо /var/log/journal не існує або Storage встановлено на auto без persistent-директорії.

Виправлення: Створіть /var/log/journal, встановіть Storage=persistent, перезапустіть journald.

6) Симптом: Ви обмежили journald, але диск все одно заповнюється

Корінна причина: Інший конвеєр логів пише в інше місце (файли rsyslog, логи застосунків), або капи журналу не застосовуються через шарування конфігурацій.

Виправлення: Перевірте systemd-analyze cat-config для journald, перевірте цілі rsyslog, і використайте du -x, щоб знайти інші місця зростання під /var.

Жарт #2: Якщо хочете почуватися всемогутнім, налаштуйте SystemKeepFree правильно і подивіться, як ваше майбутнє «я» перестане посилати сердиті повідомлення вашому минулому «я».

Чек-листи / покроковий план

Коли диск уже повний (режим інциденту)

1. Запустіть df -hT і підтвердіть, який маунт повний.
2. Заміряйте /var/log/journal і підтвердіть через journalctl --disk-usage.
3. Визначте топ-токерів за останні 5–15 хвилин (journalctl --since ... pipeline).
4. Виконайте vacuum за розміром, щоб відновити запас (journalctl --vacuum-size=...).
5. Перезапустіть journald, якщо підозрюєте відкриті видалені файли.
6. Зменшіть обсяг логів в джерелі: рівень логів, відкат, або вимкніть debug-флаги.
7. Встановіть явні ліміти і буфер keep-free через drop-in; перезапустіть journald.

План зміцнення на наступні 90 днів (нудно, правильно, ефективно)

1. Встановіть політику: Визначте намір зберігання (наприклад, 30 днів локально, 180 днів централізовано для критичних потоків).
2. Підійміть розмір сховищ: Вирішіть, чи /var/log/journal має бути на корені. Якщо ні — створіть виділений том або хоча б окремий маунт /var.
3. Реалізуйте ліміти: Використовуйте SystemMaxUse + SystemKeepFree, і часовий кап (MaxRetentionSec).
4. Робіть шторм видимим: Моніторьте повідомлення про пригнічення journald і швидке зростання journalctl --disk-usage.
5. Дотримуйтеся гігієни логів: Впровадьте правила логування: не робити дампів payload на INFO, не логувати в tight-loop без бекафу, семплуйте повторні помилки.
6. Пересилайте важливе: Забезпечте копіювання автентифікаційних, привілейованих, ядрових та розгортальних логів за межі хосту.
7. Протестуйте: У staging симулюйте шторм логів і перевірте, що ви не втрачаєте ключові докази першої відмови.

Рекомендовані числа: значення, які зазвичай працюють

• Малі кореневі диски (20–40GB): SystemMaxUse=1G–3G, SystemKeepFree=1G, MaxRetentionSec=2week–1month.
• Виділений лог-том (100GB+): SystemMaxUse=10G–50G, SystemKeepFree=5G–20G, плюс централізована пересилка.
• Ноди з високим churn: Краще виправляти шумні джерела, ніж піднімати ліміти; churn шкодить продуктивності і зношує SSD.

FAQ

1) Чи «поганий» journald порівняно з rsyslog?

Ні. journald відмінний для локального, структурованого логування з контекстом юніту. rsyslog відмінний для текстових логів і гнучкого форвардингу. У продакшні вони часто доповнюють одне одного: journald локально, пересилка централізовано.

2) Якщо я встановлю SystemMaxUse, чи припинить journald логувати при досягненні ліміту?

Він продовжить працювати, ротаючи і видаляючи старіші записи, щоб триматися в межах ліміту. Це означає, що система виживає, але старі докази витісняються. Саме тому слід пересилати критичні логи за межі хоста.

3) У чому різниця між SystemMaxUse і SystemKeepFree?

SystemMaxUse обмежує максимальний слід журналу. SystemKeepFree накладає мінімум вільного місця на файлову систему. Якщо вам важлива стабільність вузла, SystemKeepFree — це запобіжник, що не дасть «логам вбити ОС».

4) Чи варто вручну видаляти файли під /var/log/journal?

Уникайте цього. Користуйтеся journalctl --vacuum-size або --vacuum-time. Ручне видалення підвищує ймовірність відкритих видалених файлів, неконсистентності і змушує вас пропустити політичне рішення повністю.

5) Чому я бачу “Suppressed N messages” і чи панікувати?

Слід звернути увагу. Це означає, що ви втрачаєте рядки логів. Іноді це прийнятно під час шторму, але часто це симптом поламаної служби або неправильно налаштованого рівня логування. Виправляйте джерело.

6) Мені потрібні логи для аудитів. Чи можу я все одно обмежувати journald?

Так, і вам слід це робити. Розглядайте локальний journald як обмежений буфер, а потім пересилайте аудит-важливі логи в незмінне або контрольоване централізоване сховище. Аудитованість і «безмежне локальне зберігання» — різні речі.

7) А що з контейнерами — чи стає гірше?

Часто так. Контейнери часто логують в stdout, і якщо ви запускаєте багато балакучих контейнерів на хості, journald стає резервуаром для всього цього. Ваші ліміти мають це відображати, а платформа повинна примусово встановлювати рівні логів і семплування.

8) Як зрозуміти, що мої капи занадто малі?

Два ознаки: (1) ви не можете реконструювати хронологію, бо релевантні повідомлення швидко витісняються, і (2) journald постійно вакуумить/ротує під навантаженням (churn). Збільшіть капи помірно і зменшіть шум на джерелі.

9) Чи допоможе переміщення /var/log/journal на окрему файлову систему?

Так. Це ізолює домени відмов. Якщо логи заповнять логовий том, вони зазвичай не перешкоджатимуть ОС писати критичний стан на корінь. Вам все ще потрібні ліміти, але зона ураження зменшується.

10) Який найнадійніший «екстрений» спосіб очистки, якщо часу немає?

journalctl --vacuum-size=..., потім при потребі перезапустіть journald, потім виправте шумний юніт. Не починайте випадково видаляти файли під /var, коли втомлені.

Висновок: наступні кроки, які ви можете зробити вже сьогодні

Коли journald «з’їдає» ваш диск, рідко це тому, що journald «вийшов з-під контролю». Це тому, що ви не дали йому меж, і тому, що якийсь сервіс вирішив найкраще висловити свій біль через друк роману що мілісекунду.

Зробіть це далі:

1. Встановіть явні ліміти через SystemMaxUse і SystemKeepFree у drop-in, а не на пломеневу пам’ять.
2. Поєднуйте часові й розмірні політики, щоб шторм не знищив ваше розслідувальне вікно.
3. Знайдіть і виправте топ-токерів — debug-логи в продакшні обходяться вам диском і сном.
4. Пересилайте важливе за межі хосту, щоб вузол міг померти, не взявши з собою докази.
5. Моніторьте повідомлення про пригнічення; це ваше раннє попередження, що спостережуваність дає збій.

Якщо запам’ятаєте одне: обмеження логів — це не про видалення історії. Це про свідомий вибір, яку історію ви можете дозволити собі зберегти.