Ubuntu 24.04: rsyslog проти journald — обирайте логування, не втрачаючи важливих подій

January 31, 2026 • February 3, 2026 • Читання: 6 хв • Views: 10

Було корисно?

О 03:12 продукція впала. Ви зробили те, що робить кожна здорова людина: кинулися дивитися логи. І логи зробили те, що логи люблять під навантаженням: замовкли, були заротовані або взагалі не покинули машину.

Ubuntu 24.04 дає вам дві реальності логування, що співіснують поруч: systemd-journald (журнал) і rsyslog (класичний syslog). Вибір — не «сучасне проти застарілого». Це питання «які режими відмов я можу терпіти», «як довести, що я не втратив повідомлення» і «наскільки швидко я зможу відповісти командиру інциденту без здогадок».

Рішення: що варто запускати і чому

Якщо ви запускаєте Ubuntu 24.04 у продакшені і вам важливо не втрачати важливі події, зробіть так:

Залиште journald. На системах з systemd він не опціональний, і це ваш найкращий інструмент для першого огляду.
Зробіть журнал персистентним на будь‑яких хостах, які ви будете дебажити після перезавантаження.
Використовуйте rsyslog для надійного та контрольованого пересилання на центральну платформу логів (SIEM, ELK/OpenSearch, Splunk тощо), яку ваша організація вважає «джерелом правди».
Не використовуйте «переслати все двічі» як стратегію. Дублікати — це не надлишковість; це шум, який заважає помітити ту одну потрібну строку.

Іншими словами: journald — для локального захоплення, індексації та структурованих метаданих; rsyslog — для сумісності з екосистемою syslog, черг та свідомих правил пересилки. Ви можете пересилати з journald до rsyslog або налаштувати сервіси логувати безпосередньо в syslog. Правильна відповідь залежить від того, що вам потрібно довести під час інциденту або аудиту.

Суха правда: ви не обираєте систему логування за відчуттями. Обирайте її за режимом відмов. Запитайте: «що станеться, коли диск заповниться? Коли мережа відвалиться? Коли хост перезавантажиться? Коли час стрибне? Коли процес заллє логер повідомленнями?» і підберіть стек, який відмовляє так, як ви можете з цим жити.

Ментальна модель, яка не брешить під тиском

Що таке journald насправді

systemd-journald — це колектор і сховище подій логів з прикріпленими метаданими: cgroup, ім’я юніта, PID, UID, capabilities, контекст SELinux/AppArmor (де доступно), boot ID і монотонні часові мітки. Він зберігає записи у бінарних файлах журналу. «Бінарний» — це не моральна вада; це вибір на користь продуктивності та цілісності. Це дозволяє індексацію та відносно швидкі запити, наприклад «покажи все з sshd.service за останній бут».

За замовчуванням на багатьох системах journald використовує волатильне сховище (пам’ять під /run/log/journal), якщо не налаштовано персистентне сховище. Таке налаштування дружнє до малих дисків і ефермних машин, але жорстоке, коли треба розбиратися з тим, що сталося до перезавантаження.

Що таке rsyslog насправді

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

Виводи rsyslog зазвичай — текстові файли в /var/log або віддалені syslog‑приймачі. Текстові логи залишаються лінгва франка великої кількості інструментів. Це не ностальгія; це сумісність з тим, що досі парсить syslog як 2009 рік.

Пайплайн на Ubuntu 24.04 (типовий)

Повідомлення ядра потрапляють у кільцевий буфер ядра, потім journald їх збирає; rsyslog теж може читати повідомлення ядра залежно від конфігурації.
Служби systemd логують у stdout/stderr; journald автоматично їх захоплює.
Багато традиційних додатків усе ще логують через /dev/log (syslog сокет). Це може надавати rsyslog або сумісний сокет від systemd‑journald.
rsyslog може приймати дані з journald (через imjournal) або з syslog сокета, після чого писати файли і/або пересилати їх.

Якщо ви коли‑небудь дивувалися, чому у вашому /var/log/syslog бракує рядка, який ви бачили в journalctl, відповідь зазвичай: «це дві різні дороги захоплення». Логування — це ланцюг постачання. Ви не помічаєте ланцюга, поки не застрягне контейнерний корабель.

Цитата, яку варто прикріпити до монітора (перефразована думка): тема Gene Kim про операції говорить, що покращення приходить від скорочення циклів зворотного зв’язку. Логування — один з ваших найкоротших циклів; ставтеся до нього як до продакшн‑коду.

Жарт №1: Логування як зуби — ігноруєш, поки не заболіє, а тоді раптом готовий заплатити будь‑яку ціну, щоб біль припинився.

Цікаві факти та історичний контекст

syslog існує довше за Linux. Оригінальний syslog з’явився в BSD Unix у 1980‑х, створений для простого мережевого транспорту логів у часи, коли «модель безпеки» була здебільшого «не дозволяти Деві з бухгалтерії торкатися сервера».
rsyslog новіший, ніж думають багато хто. rsyslog з’явився на початку 2000‑х як сумісна заміна sysklogd з кращою продуктивністю і можливостями, такими як TCP, RELP і черги.
journald зберігає логи в бінарному форматі за задумом. Він оптимізований для індексованих запитів і подій, багатих на метадані; аргумент «бінарні логи погані» здебільшого про очікування інструментів, а не про реальну надійність.
systemd зробив stdout/stderr важливими для логування. Це змінило культуру логування додатків: службам більше не потрібно керувати лог‑файлами, якщо вони цього не хочуть. Платформа захоплює їх.
Традиційна ротація логів була винайдена для контролю використання диска для текстових логів. У journald збереження часто контролюється за розміром/часом, а не через ротацію файлів, що змінює підхід до питання «ми зберегли минулий тиждень?».
RELP існує тому, що TCP іноді недостатньо. TCP все ще може втратити дані при аварії відправника або скиданні з’єднання у невдалий момент; RELP (Reliable Event Logging Protocol) додає підтвердження на рівні застосунку.
Journald позначає логи boot ID. Це звучить як дрібниця, поки ви не дебажите переривчастий крах і не треба відокремити «цей бут» від «попереднього бута». Це дуже корисно.
Кільцевий буфер ядра обмежений. Якщо ви не прочищаєте його під час потоку, старі повідомлення ядра перезаписуються. Це не вина journald, але journald — типовий шлях їх спустошення.

Трейд‑офи, які дійсно важливі в 2025

Надійність збереження: що переживає перезавантаження, а що ні

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

rsyslog, що пише на диск, за замовчуванням персистентний (якщо він пише в /var/log і ця файлову система переживає). Але персистентність на тому ж диску, що й робоче навантаження, не рятує, якщо диск заповнюється і ваш додаток падає. Надійність — це властивість системи, а не лише демон.

Зворотний тиск та обробка вибухів

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

Метадані та зручність запитів

journald перемагає локально для швидкого розрізання: за юнітом, PID, cgroup, boot, пріоритетом, часом. Якщо ви робите інцидентний розбір на одній машині, journalctl часто швидший, ніж grep по файлах — особливо коли служби шлють структуровані дані або PID часто змінюються.

rsyslog перемагає, коли треба інтегруватися з всім, що очікує syslog — від мережевого обладнання до старих конвеєрів відповідності. Це «універсальний адаптер».

Безпека та захист від фальсифікацій

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

Складність і операційні витрати

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

Жарт №2: «Нам не потрібне централізоване логування» — смілива стратегія; це як відмовитися від ременів безпеки, бо ви плануєте їздити обережно.

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

Ось перевірки, які я виконую на Ubuntu 24.04, коли хтось каже «логи зникли», «диск заповнюється» або «пересилка не працює». Кожне завдання містить: команду, що означає вивід, і яке рішення прийняти.

Завдання 1: Підтвердити, що запущено (journald, rsyslog)

cr0x@server:~$ systemctl status systemd-journald rsyslog --no-pager
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Mon 2025-12-30 09:10:11 UTC; 2h 1min ago
...
● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 1min ago
...

Значення: Обидва сервіси активні; ймовірно у вас подвійні шляхи захоплення. Якщо rsyslog неактивний, ви, ймовірно, покладаєтесь лише на journald.

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

Завдання 2: Подивитися режим зберігання journald (volatile vs persistent)

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

Значення: Десь на диску є файли журналу. Якщо ця команда помилиться або покаже малі обсяги, але ви очікували історію, можливо, використовується тільки волатильне сховище.

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

Завдання 3: Перевірити, чи journald використовує персистентне сховище

cr0x@server:~$ ls -ld /var/log/journal /run/log/journal
drwxr-sr-x 3 root systemd-journal 4096 Dec 30 09:10 /var/log/journal
drwxr-sr-x 2 root systemd-journal  120 Dec 30 09:10 /run/log/journal

Значення: /var/log/journal існує, отже персистентність увімкнена (або принаймні доступна). Якщо її немає, journald може бути волатильним.

Рішення: Якщо /var/log/journal відсутній, створіть його і встановіть Storage=persistent (деталі в розділі плану).

Завдання 4: Перевірити налаштування збереження та обмеження швидкості journald

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

Значення: Це ефективні налаштування після drop‑in файлів. Малий SystemMaxUse означає швидше видалення старих записів. Агресивне обмеження швидкості може скидати сплески.

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

Завдання 5: Виявити відкинуті повідомлення в journald

cr0x@server:~$ journalctl -u systemd-journald --since "1 hour ago" | tail -n 8
Dec 30 10:44:02 server systemd-journald[412]: Suppressed 12845 messages from /system.slice/myapp.service
Dec 30 10:44:02 server systemd-journald[412]: Forwarding to syslog missed 0 messages

Значення: «Suppressed» вказує на відкидання через обмеження швидкості. Це не теоретично. Це відбувається тут і зараз.

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

Завдання 6: Перевірити, чи rsyslog приймає з journald

cr0x@server:~$ grep -R "imjournal" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.conf:module(load="imjournal" StateFile="imjournal.state")

Значення: rsyslog читає системний журнал через imjournal. Якщо відсутній, rsyslog може читати замість цього з /dev/log.

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

Завдання 7: Виявити дублікати подій (класичний симптом подвійного прийому)

cr0x@server:~$ sudo awk 'NR<=20{print}' /var/log/syslog
Dec 30 11:01:10 server myapp[2211]: started worker=7
Dec 30 11:01:10 server myapp[2211]: started worker=7

Значення: Та сама повідомлення двічі в один і той же час сильно натякає на подвійний прийом (наприклад, додаток логував в syslog, а journald форвардив у rsyslog також).

Рішення: Вимкніть один шлях: або перестаньте форвардити з journald у rsyslog, або перестаньте читати rsyslog з /dev/log, залежно від архітектури.

Завдання 8: Перевірити черги rsyslog і чи заблокована пересилка

cr0x@server:~$ systemctl status rsyslog --no-pager | sed -n '1,14p'
● rsyslog.service - System Logging Service
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 9min ago
   Main PID: 621 (rsyslogd)
      Tasks: 4
     Memory: 8.5M
        CPU: 1.901s
     CGroup: /system.slice/rsyslog.service
             └─621 /usr/sbin/rsyslogd -n -iNONE

Значення: Сам статус не покаже глибину черги, але підтверджує здоров’я демона і виявляє очевидні цикли падіння.

Рішення: Якщо віддалена пересилка затримується, перевірте досяжність мережі та action‑черги rsyslog (див. нижче перевірки конфігурації).

Завдання 9: Валідувати конфіг rsyslog (синтаксис, модулі, include)

cr0x@server:~$ rsyslogd -N1
rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

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

Рішення: Ніколи не перезавантажуйте rsyslog в продакшені без перевірки. Спочатку валідуйте, потім перезавантажуйте, потім підтвердіть потік повідомлень.

Завдання 10: Визначити, чи пересилка UDP (втратна) або TCP/RELP (краще)

cr0x@server:~$ grep -R "@" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.d/60-forward.conf:*.* @@logrelay.internal:514

Значення: @ означає UDP, @@ — TCP. TCP все одно може втратити при аваріях; RELP міцніший.

Рішення: Якщо вимога — «не втратити логи автентифікації», не використовуйте UDP. Використовуйте TCP з диск‑чергами або RELP, якщо ваш релей це підтримує.

Завдання 11: Перевірити, чи journald форвардить у syslog (і чи це взагалі потрібно)

cr0x@server:~$ grep -R "^ForwardToSyslog" /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
/etc/systemd/journald.conf:ForwardToSyslog=yes

Значення: journald форвардить записи в syslog сокет. Якщо rsyslog також читає з журналу, це може створювати дублікати.

Рішення: Виберіть одну точку передачі: або ForwardToSyslog (journald → syslog сокет), або rsyslog imjournal (journald → rsyslog напряму).

Завдання 12: Визначити «чому він перезавантажився?» за розбитими по бутам журналами

cr0x@server:~$ journalctl --list-boots | tail -n 3
-2 2f1c1b2dd0e84fbb9a1f66b2ff0f8d1e Sun 2025-12-29 22:10:17 UTC—Sun 2025-12-29 23:52:01 UTC
-1 7d8c0e3fa0f44a3b8c0de74b8b9f41a2 Mon 2025-12-30 00:10:06 UTC—Mon 2025-12-30 09:09:55 UTC
 0 94f2b5d9f61e4f57b5f3c3c7a9c2a1d1 Mon 2025-12-30 09:10:06 UTC—Mon 2025-12-30 11:19:44 UTC

Значення: Видно кілька бутів, отже персистентність працює. Якщо ви бачите тільки «0», ймовірно, журнал волатильний або історію витіснено.

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

Завдання 13: Швидко зібрати наратив про вимкнення/крах

cr0x@server:~$ journalctl -b -1 -p warning..emerg --no-pager | tail -n 20
Dec 30 09:09:51 server kernel: Out of memory: Killed process 2211 (myapp) total-vm:...
Dec 30 09:09:52 server systemd[1]: myapp.service: Main process exited, code=killed, status=9/KILL
Dec 30 09:09:55 server systemd[1]: Reached target Reboot.

Значення: Останній бут показує OOM kill і падіння служби, що призвело до перезавантаження. Це той «один екран», де journald відмінно показує картину.

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

Завдання 14: Підтвердити тиск на файлову систему логів

cr0x@server:~$ df -h /var /run
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   34G  4.2G  90% /
tmpfs           3.1G  180M  2.9G   6% /run

Значення: /var пучить. Якщо логи ділять кореневу файлову систему, сплеск логів може стати відмовою.

Рішення: Обмежте використання journald (SystemMaxUse), правильно настроїть ротацію текстових логів і відправляйте логи за межі хоста. Якщо потрібно, винесіть /var на окрему файлову систему в серйозних середовищах.

Завдання 15: Кількісно визначити важких споживачів журналу

cr0x@server:~$ journalctl --since "1 hour ago" -o json-pretty | head -n 20
{
        "_SYSTEMD_UNIT" : "myapp.service",
        "PRIORITY" : "6",
        "MESSAGE" : "processed batch id=9f1c...",
        "_PID" : "2211",
        "__REALTIME_TIMESTAMP" : "1735557650000000"
}

Значення: JSON‑вихід показує поля, за якими можна фільтрувати. Якщо ваш додаток спамить «processed batch …» на info рівні, це ваша проблема для диска і вашого майбутнього себе.

Рішення: Зменшіть обсяг логування на джерелі. Системи логування не заміняють метрики.

Завдання 16: Перевірити, хто має доступ до журналу (для дебагу прав)

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),4(adm)

Значення: Користувачі в групі adm часто можуть читати багато логів; доступ до journald зазвичай надають через групу systemd-journal або через sudo.

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

Плейбук швидкої діагностики

Ви на чергуванні. Алерт каже «служба впала». Хтось каже «логи зникли». Не нишпорте без порядку. Робіть так у порядку.

Перше: з’ясувати, чи події взагалі існують локально

Перевірте журнал для служби і потрібного часового проміжку. Фільтруйте за юнітом і пріоритетом. Якщо журнал має подію, у вас є локальна істина для старту розслідування.
Перевірте попередній бут. Якщо хост перезавантажився, «зниклі логи» можуть бути просто «ви дивитеся не на той бут».

cr0x@server:~$ journalctl -u myapp.service --since "30 min ago" -p info..emerg --no-pager | tail -n 30
Dec 30 11:03:01 server myapp[2211]: healthcheck failed: upstream timeout
Dec 30 11:03:02 server systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

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

Друге: визначити, чи дані відкидаються

Пошукайте повідомлення про пригнічення в journald.
Перевірте тиск на диск. Повні диски викликають дивну поведінку і відсутні записи.
Перевірте здоров’я rsyslog і валідність конфігу.

Третє: ізолювати вузьке місце — захоплення, зберігання або відправка

Вузьке місце захоплення: додаток не логує, stdout не підключено, невідповідний syslog сокет, права доступу.
Вузьке місце зберігання: journald волатильний, занадто мале збереження, диск повний, vacuuming, надмірна ротація.
Вузьке місце відправки: rsyslog пересилає UDP, немає черг, мережеві втрати, проблеми з DNS для хоста логів, помилки TLS.

Четверте: доведіть це одним контрольованим тестовим повідомленням

cr0x@server:~$ logger -p authpriv.notice "LOGTEST authpriv notice from $(hostname) at $(date -Is)"
cr0x@server:~$ journalctl --since "1 min ago" | grep LOGTEST | tail -n 1
Dec 30 11:18:22 server cr0x: LOGTEST authpriv notice from server at 2025-12-30T11:18:22+00:00

Інтерпретація: Якщо воно в журналі, але не в /var/log/syslog (або не в вашому аггрегаторі), ви звузили помилку до шляху передачі/пересилки.

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

1) «Логи зникають після перезавантаження»

Симптоми: journalctl --list-boots показує лише бут 0; після краху історія відсутня.

Корінь проблеми: journald використовує волатильне сховище (/run), бо персистентність не увімкнена або /var/log/journal не існує.

Виправлення: Створіть /var/log/journal, встановіть Storage=persistent, перезапустіть journald і підтвердіть, що з’являються кілька бутів. Також задайте обмеження зберігання, щоб персистентність не перетворилася на виснаження диска.

2) «У нас всілякі дублікати»

Симптоми: Та сама строка з’являється двічі в /var/log/syslog або двічі в агрегаторі, часто з ідентичними часами.

Корінь проблеми: Подвійний прийом: додаток логував у syslog сокет, journald форвардив у syslog, і rsyslog також читає журнал (або навпаки).

Виправлення: Виберіть один шлях: rsyslog читає через imjournal або journald форвардить у syslog сокет. Не комбінуйте без свідомої логіки дедуплікації.

3) «Логи автентифікації відсутні в центральній системі, але локальний syslog їх має»

Симптоми: /var/log/auth.log локально заповнений; SIEM пропускає записи під час мережевих перебоїв.

Корінь проблеми: UDP‑пересилка, або TCP без диск‑черг, або релей недоступний без буферизації.

Виправлення: Використовуйте TCP з чергами на диск або RELP до релея, що призначене для інжесту. Перевірте налаштування черг і протестуйте, тимчасово блокуючи мережу.

4) «Під час інциденту journalctl повільний або таймаутить»

Симптоми: journalctl запити займають багато часу, CPU стрибки, I/O‑wait.

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

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

5) «/var повний і тепер все горить»

Симптоми: Служби не стартують, оновлення пакетів падають, логи перестають писатися, випадкові демони падають.

Корінь проблеми: Невпорядковані текстові логи, неправильно налаштований retention journald або додаток, що пише у великих обсягах.

Виправлення: Встановіть обмеження journald (SystemMaxUse, SystemKeepFree), переконайтеся, що logrotate працює, і виправте шумний додаток. Якщо середовище важливе, винесіть /var на окрему файлову систему.

6) «Я бачу логи з sudo, але не як мій on‑call користувач»

Симптоми: journalctl показує «No journal files were found» або доступ заборонено без sudo.

Корінь проблеми: Користувач черговий не в потрібній групі (systemd-journal або adm залежно від політики), або застосовано загартовані права.

Виправлення: Надати контрольований доступ для читання через членство в групі, а не через спільні root‑облікові дані, і задокументувати це.

Три корпоративні міні‑історії з логувальних фронтів

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

Середня компанія мігрувала флот з Ubuntu 20.04 на 24.04. У них був випробуваний ру‑бук: перевірити /var/log/syslog, перевірити /var/log/auth.log, відправити в центральний syslog. Міграція «працювала», сервіси піднялися, і команда пішла далі.

Дві тижні потому партія нод перезавантажилася через kernel panic, спричинений проблемною прошивкою NIC. На чергуванні відкрили /var/log/syslog і побачили… небагато. Схоже, машина просто акуратно перезавантажилася. Командир інциденту попросив «останні 60 секунд». Часу було 3 секунди і зростаюче відчуття жаху.

Хибне припущення було тонким: вони думали, що rsyslog все ще основний колектор для всього важливого. Але кілька сервісів були systemd‑нативними і логували в stdout; journald їх захоплював, і лише частина таких подій пересилалася в rsyslog. Відсутні події не «зникли». Вони сиділи в волатильному журналі, який зник після перезавантаження на деяких профілях нод.

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

Міні‑історія 2: Оптимізація, що відвернулась

Велика внутрішня команда вирішила, що вони платять занадто багато за зберігання логів. Помітили, що журнал росте швидко на галасливих нодах. Тому вони агресивно зменшили збереження journald і загострили обмеження швидкості. Мета була розумною: захистити диски і зменшити шум.

Місяць все виглядало добре. Використання диска впало. Дашборди стали чистішими. Потім залежність почала поводитися некоректно: переривчасті помилки TLS між сервісами. Помилки тривали секунди, кілька разів на годину. Метрики показували спайки помилок, але логи, які могли пояснити «чому», часто були відсутні. Спайки були саме того типу, які пригнічуються лімітами і коротким збереженням, коли багато компонентів стають галасливими одночасно.

Вони нарешті виявили патерн, корелюючи декілька вцілілих логів з пакетними дампами: MTU mismatch після зміни мережі. Справжній урок був не в MTU. Вони «оптимізували» логування, видаливши саме ті дані, які потрібні для дебагу рідкісних подій, які неможливо відтворити на вимогу.

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

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

Команда, що працює з платіжними сервісами, запускала Ubuntu‑ноди для автентифікації. Нудна конфігурація: systemd служби, rsyslog‑форвардинг і центральний релей логів. У них була одна звичка, що здавалася надміру: щоквартально вони робили контрольований тест «збоїв пересилки логів» в робочий час на канарній ноді.

Тест був простий. Блокували egress до релея логів на кілька хвилин на канарі, генерували кілька logger тестових повідомлень різних фейсиліті і пріоритетів, потім знову відкривали egress. Очікування: повідомлення чергуються локально і з’являються в агрегаторі у правильному порядку без втрат.

Одного кварталу тест провалився. Повідомлення ніколи не з’явилися upstream. Локальні логи були, але пересилка не наздогнала. Оскільки це був тест, а не реальний збій, вони мали час розбиратися без адреналіну. Виявилося, що зміна конфігу тимчасово переключила пересилку на UDP і ніхто не повернув назад. «Тимчасово» — найпостійніше слово в корпоративній ІТ.

Вони відкотилися до TCP з диск‑чергами і написали маленький CI‑чек, що фіксує UDP‑форвардинг у продуктивних конфігах. Місяць потому справжній мережевий інцидент вдарив по сегменту дата‑центру. Черга поглинула відключення, SIEM пізніше синхронізувався, і звіт про інцидент містив незвичну фразу: «Втрата даних не виявлена». Нудне виграло. Знову.

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

План A (рекомендовано): персистентний journald + пересилка через rsyslog з одним шляхом прийому

Зробіть journald персистентним.
```
cr0x@server:~$ sudo mkdir -p /var/log/journal
cr0x@server:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
cr0x@server:~$ sudo sed -i 's/^#Storage=.*/Storage=persistent/' /etc/systemd/journald.conf
cr0x@server:~$ sudo systemctl restart systemd-journald
```
Що перевірити: journalctl --list-boots має показати більше ніж бут 0 після наступного перезавантаження, і /var/log/journal має наповнитися.
Встановіть обмеження зберігання, що не заповнять диск.
```
cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/99-retention.conf >/dev/null <<'EOF'
[Journal]
SystemMaxUse=2G
SystemKeepFree=1G
MaxRetentionSec=14day
EOF
cr0x@server:~$ sudo systemctl restart systemd-journald
```
Рішення: Обирайте ліміти відповідно до розміру диска і потреб інцидентів. На маленьких root‑файлових системах будьте консервативні і пересилайте логи за межі хоста.
Виберіть точку передачі в rsyslog: використовуйте imjournal АБО ForwardToSyslog, але не обидва.

Опція 1 (поширена): rsyslog читає журнал через imjournal.
```
cr0x@server:~$ sudo grep -R "module(load=\"imjournal" /etc/rsyslog.conf
module(load="imjournal" StateFile="imjournal.state")
```
Тоді відключіть пересилання journald у syslog, щоб уникнути дублювання, якщо ви не використовуєте його:
```
cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/10-forwarding.conf >/dev/null <<'EOF'
[Journal]
ForwardToSyslog=no
EOF
cr0x@server:~$ sudo systemctl restart systemd-journald
```

Використовуйте надійну пересилку (TCP + черги; RELP якщо доступно).

cr0x@server:~$ sudo tee /etc/rsyslog.d/60-forward.conf >/dev/null <<'EOF'
# Forward everything to a relay over TCP with a disk-assisted queue.
# Adjust rules so you don't forward noisy debug logs if you don't need them.

action(
  type="omfwd"
  target="logrelay.internal"
  port="514"
  protocol="tcp"
  action.resumeRetryCount="-1"
  queue.type="LinkedList"
  queue.filename="fwdAll"
  queue.maxdiskspace="2g"
  queue.saveonshutdown="on"
  queue.dequeuebatchsize="500"
)
EOF
cr0x@server:~$ sudo rsyslogd -N1
cr0x@server:~$ sudo systemctl restart rsyslog

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

Доведіть кінець‑в‑кінець за допомогою контрольних повідомлень.
```
cr0x@server:~$ logger -p user.notice "LOGPIPE e2e test id=$(uuidgen)"
cr0x@server:~$ journalctl --since "2 min ago" -o short-iso | grep LOGPIPE | tail -n 1
2025-12-30T11:20:41+00:00 server cr0x: LOGPIPE e2e test id=3e0c2aef-7e0f-4a43-a3c2-9c3e5c4f2f8b
```
Рішення: Якщо воно локально, але не централізовано — лаг на шляху пересилки. Якщо воно й локально не з’являється — проблема захоплення.

План B: тільки journald (прийнятно для ефермних флотів з сильною централізацією)

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

План C: rsyslog як основний (лише за спадщинними обмеженнями)

Можливо, але у вас все одно буде journald, що захоплює stdout/stderr для systemd‑сервісів.
Якщо наполягаєте на файлових workflow‑ах, переконайтеся, що служби логують у syslog або файли свідомо. Інакше ви будете шукати відсутні події в двох світах.
Будьте явними щодо джерел логів ядра, щоб уникнути розривів.

Питання та відповіді

1) На Ubuntu 24.04, чи потрібен мені взагалі rsyslog?

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

2) Чи може journald втратити логи?

Може. Якщо налаштовано волатильне сховище, логи не переживуть перезавантаження. Якщо спрацюють ліміти швидкості, воно може пригнічувати повідомлення під час сплесків. Якщо диск повний або caps малі — старі записи вакуумуються. Це не зло; це фізика.

3) Чи є бінарні логи проблемою для комплаєнсу?

Зазвичай вимога комплаєнсу — «зберігання, цілісність, контроль доступу, аудит», а не «повинно бути plain text». Справжній крок для комплаєнсу — пересилання логів за межі хоста в незмінне сховище і контроль доступу. Бінарний чи текстовий формат — це перевага інструментів, а не гарантія.

4) Чому я бачу логи в journalctl, але не в /var/log/syslog?

Тому що journald за замовчуванням захоплює stdout/stderr для systemd‑сервісів. Якщо ви не форвардите ці записи в syslog, вони не з’являться в syslog‑файлах. Також фільтри або мапінги фейсиліті можуть направляти повідомлення інакше.

5) Чи форвардити з journald у rsyslog чи нехай rsyslog читає журнал?

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

6) Чи прийнятний UDP для пересилки syslog?

Для «низьких ставок» телеметрії і шумних debug‑стрімів, де втрата допустима — так. Для auth, безпеки або критичних інцидентів — ні. Використовуйте TCP з буферизацією або RELP, якщо можете.

7) Скільки збереження в journald варто тримати?

Тримайте достатньо, щоб покрити ваш вікно реакції людини: щонайменше «попередній бут + кілька днів» на важливих хостах. Далі покладайтеся на центральне збереження для тижнів/місяців. Обмежте локальне використання, щоб воно не з’їло машину.

8) Чи можу я змусити journald писати традиційні текстові логи напряму?

Не як основний формат. journald може форвардити в syslog, а syslog‑демони можуть писати текстові файли. Це підтримуваний міст: journald захоплює, rsyslog пише/пересилає.

9) А як щодо логів контейнерів?

Якщо контейнери логують у stdout/stderr і рантайм інтегрується з systemd, journald може їх захоплювати з багатими метаданими. Якщо ви використовуєте інший шлях рантайму, переконайтеся, що ваш колектор явно знімає логи контейнера. Не припускайте.

10) Як запобігти тому, щоб логи не вбили вузол?

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

Висновок: наступні кроки, які вас не підведуть

Ubuntu 24.04 не змушує вас воювати релігійно між journald і rsyslog. Вона дає два інструменти з різними режимами відмов. В продакшені правильний патерн зазвичай такий: персистентний journald як локальна істина плюс rsyslog для свідомої, буферизованої, сумісної пересилки.

Наступні кроки:

Увімкніть персистентність journald на будь‑якому хості, який ви можете відлагоджувати після перезавантаження, і обмежте її так, щоб вона не змогла заповнити диск.
Визначте один шлях прийому в rsyslog, щоб уникнути дублювань.
Переключіть пересилку на TCP (або RELP) з диск‑чергами для всього, що ви не можете дозволити собі втратити.
Щоквартально проводьте тест «відмова пересилки логів» на канарі. Якщо це здається надмірним, зачекайте перший аудит або інцидент з безпекою.

Логування — це не просто спостережуваність. Це доказ. Будуйте його так, ніби він вам знадобиться в суді — бо колись, в межах організації, це станеться.