Керування логами Linux: Використання команд journalctl для логів systemd

Рівень: Початківець
Орієнтовний час: ~20 хвилин
Мета: Навчитися запитувати, фільтрувати та керувати системними логами і логами сервісів, використовуючи логи усунення несправностей Linux для вирішення проблем та підтримки аптайму сервера.

Вступ

Надійне керування логами Linux має важливе значення для підтримки аптайму сервера та діагностики серверів Linux. Під час керування веб-серверами вам потрібно швидко аналізувати системні логи за допомогою journalctl, щоб знайти першопричину проблеми. Systemd (система ініціалізації та диспетчер служб для більшості сучасних дистрибутивів Linux) збирає системні логи (загальні записи операцій системи та загальносистемних подій). Окремий лог (запис подій, які відбуваються в операційній системі або програмному додатку) збирається Systemd-journald (системною службою, яка збирає та зберігає дані логування) і зберігається у Journal (двійкові дані логів, що генеруються та управляються systemd-journald). Для перегляду цих даних ми використовуємо Journalctl (утиліту командного рядка, що використовується для запиту та відображення логів із systemd). У цьому посібнику основна увага приділяється використанню команд journalctl для запиту, фільтрації та керування логами journalctl systemd. До кінця ви будете впевнено орієнтуватися в командному рядку та використовувати логи усунення несправностей Linux для ефективного вирішення проблем.

Попередні вимоги

Перед початком переконайтеся, що виконані такі умови:

• Операційна система: Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 або AlmaLinux/Rocky 8/9/10
• Вимоги до обладнання та мережі: Немає (в цьому посібнику використовуються базові утиліти командного рядка)
• Доступ: sudo або root доступ до сервера
• Необхідні знання: базове використання командного рядка Linux

Крок 1: Керування логами Linux: Розуміння енергозалежних та постійних логів

За замовчуванням деякі системи налаштовують журнал на використання енергозалежних логів (логи зберігаються лише в оперативній пам'яті та втрачаються під час перезавантаження). Для ефективного керування логами Linux нам потрібні постійні логи (логи, які зберігаються на диск при перезавантаженнях), щоб ви могли досліджувати збої після перезапуску.

Виконайте таку команду, щоб перевірити конфігурацію вашого сховища:

sudo grep -i 'storage' /etc/systemd/journald.conf

Очікуваний вивід:

#Storage=auto

Ви повинні побачити вивід, який вказує, чи встановлено сховище у значення auto, persistent або volatile. Закоментоване #Storage=auto означає, що використовується поведінка за замовчуванням auto.

В Ubuntu 24.04 та Debian 13 каталог /var/log/journal вже існує, і постійне логування працює з коробки. Якщо каталог відсутній (наприклад, при свіжому встановленні AlmaLinux) і ви хочете примусово включити постійне логування, створіть каталог і перезапустіть систему логування systemd (служба systemd-journald керує цим каталогом):

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

Для систем AlmaLinux/RHEL ви також повинні скинути логи з енергозалежного розташування /run/log/journal у нове постійне дискове сховище:

sudo journalctl --flush

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

Крок 2: Основні команди journalctl для логів systemd

Щоб переглянути всі доступні записи, використовуйте команду за замовчуванням.

Виконайте таку команду:

sudo journalctl

Очікуваний вивід:

May 20 10:00:00 server systemd[1]: Started Logging Service.
May 20 10:00:01 server kernel: Linux version 5.15.0-101-generic...

Ви повинні побачити посторінковий список усіх логів systemd на вашому сервері. Натисніть q, щоб вийти з пейджера.

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

Виконайте таку команду:

sudo journalctl -r

Очікуваний вивід:

May 23 20:00:00 server sshd[1234]: Accepted publickey for user from 192.168.1.50...
May 23 19:59:58 server systemd[1]: Session 4 created for user.

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

Крок 3: Як перевірити логи сервісів

Часто вам потрібно усунути несправності в певному юніті (Unit) (об'єкті, яким вміє керувати systemd), такому як юніт сервісу (service unit) (конкретний тип юніта, який керує сервісом, наприклад nginx або sshd). Використовуйте прапорець -u, щоб перевірити логи сервісів для конкретних сервісів, таких як веб-сервер nginx.

Виконайте таку команду (припускаючи, що ви встановили службу, наприклад, за допомогою sudo apt install nginx -y або sudo dnf install nginx -y):

sudo journalctl -u nginx

Очікуваний вивід:

May 23 18:00:00 server systemd[1]: Starting A high performance web server and a reverse proxy server...
May 23 18:00:01 server systemd[1]: Started A high performance web server and a reverse proxy server.

Ви повинні побачити лише записи логів, згенеровані службою nginx. Це допомагає ізолювати помилки веб-трафіку від інших фонових системних подій. Якщо служба не встановлена, ви просто побачите -- No entries --.

Щоб перевірити логи сервісу для демона SSH, ім'я юніта залежить від дистрибутива.

Для Ubuntu/Debian виконайте:

sudo journalctl -u ssh

Для AlmaLinux/RHEL/Rocky виконайте:

sudo journalctl -u sshd

Очікуваний вивід:

May 23 19:50:00 server sshd[1234]: Invalid user admin from 10.0.0.5 port 55432
May 23 19:55:00 server sshd[1235]: Accepted publickey for root from 10.0.0.2 port 44322

Ви повинні побачити спроби автентифікації та події демона SSH.

Крок 4: Фільтрація логів journalctl за часом і типом

Під час роботи з великими обсягами даних вам потрібна фільтрація логів (процес звуження виводу логів на основі певних критеріїв). Фільтрація логів journalctl за часом неймовірно корисна, коли збій стався у відомий час.

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

Виконайте таку команду:

sudo journalctl -b

Очікуваний вивід:

May 23 08:00:00 server kernel: Linux version 5.15.0-101-generic...
May 23 08:00:00 server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz...

Ви повинні побачити вивід, починаючи з найпершої події поточної послідовності завантаження.

Для фільтрації логів journalctl за часом використовуйте --since та --until.

Виконайте таку команду:

sudo journalctl --since "1 hour ago"

Очікуваний вивід:

May 23 19:00:00 server cron[567]: (root) CMD (/usr/local/bin/backup.sh)
May 23 19:05:00 server sudo[580]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls

Ви повинні побачити всі події, що відбулися за останні 60 хвилин.

Щоб переглянути логи ядра (повідомлення, що генеруються ядром Linux, зазвичай події обладнання та драйверів), використовуйте прапорець -k.

Виконайте таку команду:

sudo journalctl -k

Очікуваний вивід:

May 23 08:00:00 server kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex
May 23 08:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

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

Крок 5: Фільтрація за пріоритетом

Кожен запис має Пріоритет (рівень серйозності, присвоєний повідомленню логу). Рівні варіюються від Debug (найнижчий рівень пріоритету, який використовується для отримання детальної інформації про усунення несправностей) до Error (рівень пріоритету, що вказує на збій у службі або процесі). Рівнем, що часто перевіряється, є Warning (рівень пріоритету, що вказує на потенційні проблеми, які наразі не є помилками).

Для фільтрації логів journalctl за пріоритетом використовуйте прапорець -p.

Виконайте таку команду, щоб побачити лише помилки:

sudo journalctl -p err

Очікуваний вивід:

May 23 10:15:20 server systemd[1]: Failed to start Custom Application Service.
May 23 14:30:00 server sshd[1122]: error: kex_exchange_identification: Connection closed by remote host

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

Виконайте таку команду, щоб побачити попередження та помилки:

sudo journalctl -p warning

Очікуваний вивід:

May 23 10:15:15 server systemd-udevd[330]: vda: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vda' failed with exit code 1.
May 23 10:15:20 server dhcpcd[400]: eth0: no IPv6 Routers available

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

Крок 6: Як моніторити логи Linux в реальному часі

Під час застосування змін конфігурації або відтворення проблеми найкраще моніторити логи Linux в реальному часі. Використовуйте прапорець -f (follow).

Виконайте таку команду:

sudo journalctl -f

Очікуваний вивід:

May 23 20:05:00 server sudo[2001]: user : TTY=pts/1 ; PWD=/ ; USER=root ; COMMAND=/bin/bash
May 23 20:05:00 server su[2002]: (to root) user on pts/1
May 23 20:05:00 server su[2002]: pam_unix(su:session): session opened for user root by user(uid=1000)

Ви повинні побачити останні записи логів, і термінал зависне, виводячи нові події в міру їх виникнення. Натисніть Ctrl+C для виходу.

Щоб моніторити логи Linux в реальному часі для демона SSH, ім'я юніта залежить від дистрибутива.

Для Ubuntu/Debian виконайте:

sudo journalctl -u ssh -f

Для AlmaLinux/RHEL/Rocky виконайте:

sudo journalctl -u sshd -f

Очікуваний вивід:

May 23 20:10:15 server sshd[2100]: Connection from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: Accepted publickey for admin from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: pam_unix(sshd:session): session opened for user admin by (uid=0)

Ви повинні побачити спроби автентифікації SSH у реальному часі в міру їх виникнення.

Крок 7: Дисковий простір та ротація логів

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

Виконайте таку команду:

sudo journalctl --disk-usage

Очікуваний вивід:

Archived and active journals take up 200.0M in the file system.

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

Для виконання ручної ротації логів та звільнення дискового простору ви можете очистити (vacuum) дані за часом або розміром.

Виконайте таку команду, щоб залишити лише останні 500 МБ даних:

sudo journalctl --vacuum-size=500M

Очікуваний вивід:

Vacuuming done, freed 0B of archived journals from /var/log/journal.

Ви повинні побачити вивід, який вказує, що старі файли були видалені, поки загальний розмір не став менше 500 МБ.

Перевірка

Щоб переконатися, що ваше налаштування логування працює правильно і постійне сховище активне:

1. Переконайтеся, що каталог зберігання логів був створений:

   ls -ld /var/log/journal

   Ви повинні побачити каталог, що належить root. Залежно від вашого дистрибутива, група може бути systemd-journal або root (обидва варіанти є нормою).

2. Переконайтеся, що journald активно працює:

   sudo systemctl status systemd-journald

   Ви повинні побачити, що служба у стані active (running).

Усунення несправностей

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

• Порожні логи сервісів (-- No entries --): Переконайтеся, що служба дійсно встановлена та запущена. Також перевірте, чи використовуєте ви правильне ім'я юніта для вашого дистрибутива (наприклад, ssh в Debian/Ubuntu порівняно з sshd в RHEL/AlmaLinux).
• Відсутній /var/log/journal: У деяких системах (таких як AlmaLinux) ви повинні вручну створити цей каталог і перезапустити службу логування, щоб увімкнути постійні логи. Якщо ви пропустите цей крок, логи залишаться в енергозалежній пам'яті (/run/log/journal).
• У доступі відмовлено: Якщо ви не можете читати логи без sudo, переконайтеся, що ваш користувач входить до групи systemd-journal або adm (sudo usermod -aG systemd-journal $USER).

Скасування змін

Якщо ви хочете вимкнути постійне логування і повернутися до енергозалежних логів (наприклад, для економії дискового простору):

1. Видаліть каталог постійного сховища:

   sudo rm -rf /var/log/journal

2. Перезапустіть службу логування, щоб відтворити енергозалежне сховище в /run/log/journal:

   sudo systemctl restart systemd-journald

Висновок

На цьому все. Тепер ви розумієте основи керування логами Linux. Використовуючи правильні команди journalctl, ви можете ефективно орієнтуватися в логах systemd, застосовувати фільтри та керувати дисковим простором. Незалежно від того, чи потрібно вам аналізувати логи за допомогою journalctl після збою або просто перевіряти регулярний стан служб, опанування journalctl є важливим кроком у підтримці здорової інфраструктури.

Версія документа: 1.0
Останнє оновлення: Травень 2026
Власник: Команда технічної документації