Збір логів Linux через systemd-journald закриває базову задачу на сервері або в homelab: прийняти журнали сервісів, зберегти їх після перезавантаження і не дати їм безконтрольно з’їсти диск. Нижче – практична схема: постійне зберігання, обмеження обсягу, ротація, очищення і перевірка результату.
Якщо journald залишити в стані за замовчуванням, поведінка часто виявляється неочевидною. На одних системах логи зберігаються лише до ребута, на інших – накопичуються роками, поки не закінчиться місце. Для домашнього сервера це дрібниця рівно до першої аварії, після якої потрібний журнал уже зник або витіснений шумом.
Суть нормального налаштування проста: journald має писати в persistent storage, тримати жорстку межу по диску, віддавати старі записи під вакуумування і не конкурувати з окремим syslog-демоном без потреби. Саме цей варіант найкраще працює для одиночних вузлів, Proxmox-хостів, домашніх VM і невеликих self-hosted інсталяцій.
Що саме робить journald і де він ламає очікування
systemd-journald – це сервіс журналювання в Linux, який збирає повідомлення ядра, systemd unit-файлів і локальних сервісів. Він зберігає записи у власному двійковому форматі, тому пошук, фільтрація за unit, boot або пріоритетом працюють швидко. Проблеми починаються не тут, а на межі між volatile і persistent storage.
Найчастіша пастка – відсутність постійного каталогу для журналів. У такому режимі все працює, поки вузол не перезавантажився. Після цього історія зникає, а діагностика збою перетворюється на ворожіння. Друга типова помилка – тримати journald і rsyslog паралельно без чіткої ролі кожного. На невеликому хості це дає дублювання, зайвий I/O і шум у підтримці.
Практична межа теж є. Для одного сервера або невеликого homelab journald достатньо. Якщо логи треба централізувати з кількох вузлів, довго зберігати або шукати по всій інфраструктурі, локальний журнал уже не вирішує задачу повністю. Там потрібен окремий стек збору.
Як увімкнути постійне зберігання journald
Щоб збір логів Linux переживав reboot, journald має писати в каталог /var/log/journal і мати режим Storage=persistent. На багатьох дистрибутивах достатньо створити каталог і перезапустити сервіс. Але коректніше одразу зафіксувати це в конфігурації.
Основний файл – /etc/systemd/journald.conf. Якщо система керується drop-in файлами, безпечніше змінювати окремий файл у /etc/systemd/journald.conf.d/, щоб не чіпати дефолти пакета.
sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo mkdir -p /etc/systemd/journald.conf.d sudo nano /etc/systemd/journald.conf.d/persistent.conf
Вміст drop-in може виглядати так:
[Journal] Storage=persistent
Після цього сервіс треба перезапустити:
sudo systemctl restart systemd-journald
На практиці цього вже достатньо, щоб збір логів Linux перестав бути тимчасовим. Якщо після перезапуску каталог порожній, причина зазвичай в правах, read-only файловій системі або в тому, що конфіг перекривається іншим drop-in.
Як обмежити розмір журналу і налаштувати ротацію
У journald немає класичної logrotate-схеми з текстовими файлами. Ротація тут працює через власні ліміти: загальний розмір журналу, розмір окремих файлів і час зберігання. Це важливо розуміти, інакше адміністратор починає шукати logrotate там, де він не бере участі.
Для домашнього сервера або одиночного Linux-хоста зазвичай достатньо трьох речей: ліміт на весь persistent journal, межа для volatile storage і політика утримання за часом. Нижче – стриманий профіль, який не дає логам розростатися безконтрольно.
[Journal] Storage=persistent SystemMaxUse=1G RuntimeMaxUse=256M SystemKeepFree=500M MaxRetentionSec=1month
SystemMaxUse обмежує місце під постійні журнали. RuntimeMaxUse стосується тимчасового зберігання в /run. SystemKeepFree залишає вільний простір на файловій системі. MaxRetentionSec обрізає надто старі записи за часом, якщо дистрибутив і версія systemd це підтримують.
Тут є неочевидний момент. Якщо поставити лише часовий ліміт, без межі по обсягу, при сплеску шумних логів диск можна забити задовго до настання retention window. Саме тому для homelab надійніше мислити від дискового бюджету, а не від кількості днів.
Після змін конфігурації знову потрібен перезапуск:
sudo systemctl restart systemd-journald
Як вручну очистити старі логи в journald
Коли місце вже закінчується, чекати природної ротації пізно. Для цього journald має команди vacuum, які видаляють архівні журнали за розміром або віком. Це швидший і безпечніший шлях, ніж ручне видалення файлів з каталогу журналу.
sudo journalctl --disk-usage sudo journalctl --vacuum-size=500M sudo journalctl --vacuum-time=14d
Спочатку варто подивитися фактичний обсяг через –disk-usage. Потім зменшити історію або за розміром, або за часом. Команди vacuum працюють тільки з архівними файлами. Якщо активний journal великий, ефект може бути меншим, ніж очікується, доки не відбудеться rotate.
Примусова ротація теж доступна:
sudo journalctl --rotate sudo journalctl --vacuum-size=500M
Саме така зв’язка часто рятує вузол, на якому spam у логах уже пішов у гігабайти. Просте видалення каталогу журналів виглядає спокусливо, але це грубіший сценарій, після якого легко отримати биті очікування щодо прав, індексів або поведінки сервісу після reboot.
Як перевірити, що збір логів Linux і ротація працюють
Перевірка має підтвердити три речі: journald пише в persistent storage, бачить старі boot-сесії і поважає ліміти. Якщо перевіряти тільки командою journalctl -xe, цього недостатньо – вона показує поточну картину, але не гарантує правильне зберігання після перезавантаження.
- Перевірити статус сервісу:
systemctl status systemd-journald
- Подивитися, чи є журнали попередніх завантажень:
journalctl --list-boots
- Перевірити фактичний обсяг:
journalctl --disk-usage
- Переконатися, що читаються записи конкретного сервісу:
journalctl -u ssh journalctl -u docker
- Після reboot повторити journalctl –list-boots і звірити, що попередній boot залишився в історії.
Якщо boot-історії немає, persistent storage не активувався. Якщо обсяг росте понад виставлені межі, треба перевіряти, чи параметри реально підхоплені, і чи не перекриває їх інший конфіг. У системах з агресивним log spam проблема інколи не в journald, а в сервісі, який ллє тисячі однакових повідомлень. Ротація це маскує, але не вирішує.
Де journald зазвичай створює проблеми в homelab
Найчастіше journald підводить не через збір логів Linux як такий, а через неправильні очікування. Адміністратор бачить, що логи читаються, і вважає задачу закритою. Потім з’ясовується, що після ребута історії немає, або NVMe постійно ловить зайвий дрібний запис від шумного контейнера.
Для контейнерних хостів є окрема межа застосовності. Якщо Docker або Podman пишуть великий потік у journald, локальний журнал швидко перетворюється на буфер, а не на сховище для аналізу. На кількох контейнерах це ще терпимо. На щільному хості логічніше або жорстко обмежити шум, або виносити агрегацію в окрему систему.
Ще одна проблема – дублювання з rsyslog або syslog-ng. Якщо потрібна лише локальна діагностика і фільтрація по unit, одного journald зазвичай достатньо. Якщо потрібен форвардинг у SIEM, текстові файли для старих агентів або сумісність із застарілими пайплайнами, тоді journald варто лишати як локальний буфер, а не як єдину точку істини.
Коли journald вже не вистачає
Journald добре закриває локальний збір логів Linux на одному вузлі або в малій групі машин. Але він не замінює централізоване журналювання. Якщо треба шукати події між кількома серверами, зберігати історію довго або будувати алерти, потрібен окремий стек – наприклад Loki, Elasticsearch/OpenSearch або інша система агрегації.
Для homelab це нормальна точка росту. Спочатку – чистий локальний journald з нормальними лімітами. Далі, коли з’являється кілька хостів, reverse proxy, контейнерний кластер або домашній моніторинг, журнали краще виводити назовні. Локальний journal при цьому лишається першим місцем для швидкої діагностики після збою.
Офіційна документація systemd доступна на сайті freedesktop.org. Опис команди journalctl корисний для перевірки підтримуваних параметрів на конкретній системі.
Що варто залишити в робочій конфігурації
Робочий мінімум виглядає так: persistent storage, жорсткий ліміт по диску, перевірка через journalctl –list-boots і разове vacuum-очищення для аварійних ситуацій. Цього вистачає, щоб збір логів Linux був передбачуваним, а не випадковим побічним ефектом systemd.
Якщо вузол шумний або контейнерів стає забагато, journald не треба ламати тонкими тюнами. Краще раніше визнати межу: локальний журнал для швидкої діагностики, зовнішня система для довгого зберігання і пошуку. Саме така схема переживає ріст інфраструктури без зайвого хаосу.