Стаття також доступна російською (перейти до перегляду).

Зміст:

• Як працює журнальна служба в systemd
• Фільтрація виводу за часом
  • Період поточного сеансу
  • Попередні сеанси завантаження
  • Визначені проміжки часу
• Фільтрація за рівнем важливості повідомлень
  • За ідентифікатором
  • За програмними одиницями
  • За пріоритетом
• Зміна формату відображення або виводу даних
• Використання grep та awk для фільтрування записів
• Прибирання журналів

Однією з найкращих можливостей systemd в Linux є централізоване журналювання всіх процесів та подій, котрі виникають під час роботи системи. При цьому обсяг журналів може бути доволі значним, що вимагає вміння правильно ними користуватися. Системна утиліта journalctl для доступу до даних журнальної служби systemd надає змогу реалізувати будь-який запит на вибірку даних за допомогою набору параметрів для її запуску. Розглянемо способи її використання на практичних прикладах, реалізованих на VPS-сервері Debian 12.  

Як працює журнальна служба в systemd

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

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

• Json;

• Json-sse – Json у оболонці, сумісній із операцією add sse(server-sent event);

• Json-pretty – структурований Json;

• Export – двійковий формат, може використовуватися для експорту даних;

• Short – формат syslog, встановлений за замовчуванням;

• Verbose – вивід значень усіх полів журнальної системи.

Утиліта journalctl забезпечує виконання запитів на відображення повідомлень у одному з вказаних форматів та дозволяє здійснювати фільтрацію виводу за наступними критеріями:

• За часом;

• За рівнем важливості повідомлень;

• За рахунок зміни формату відображення.

Нижче буде розглянуто роботу утиліти для кожного з вказаних критеріїв.

Фільтрація виводу за часом

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

Продемонструємо це. Введемо в терміналі:

$ journalctl

Якщо ж треба врахувати час роботи системи, то тут можна спиратися на наступні часові орієнтири або покажчики: 

• Період роботи системи під час поточного сеансу завантаження;

• Часові періоди попередніх завантажень;

• Визначені проміжки часу.

Розглянемо кожний із варіантів.

Період поточного сеансу

У цьому випадку увесь вивід з журналів буде стосуватися лише поточного сеансу роботи із системою або поточного завантаження. Для цього використовується параметр -b.

Виведемо в терміналі записи поточного завантаження: 

$ journalctl -b

Попередні сеанси завантаження

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

Включимо її. Для цього відредагуємо файл конфігурації: 

$ sudo nano /etc/systemd/journald.conf

Введемо наступне значення параметру Storage:

[Journal]
Storage=persistent

Збережемо внесені зміни та вийдемо з редактору (ctrl+X).

Після цього стане можливим працювати із даними сеансів попередніх завантажень, як із окремими одиницями. Для цього передбачено ряд команд.

Наприклад, продивимося список всіх доступних journald сеансів попередніх завантажень. Для цього введемо в терміналі:

$ journalctl --list-boots

Тут кожний запис відповідає окремому сеансу завантаження. У першому стовпчику вказані відносні ідентифікатори сеансів, в другому – абсолютні. Для виводу даних будь-якого сеансу можна вказати будь-який з цих ідентифікаторів.

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

$ journalctl -b -3

Так само ми могли б вказати і абсолютний ідентифікатор того ж сеансу:

$ journalctl -b c141d403dd4d4d59b5c8d20f76cd5d75

Результат був би тим самим.

Визначені проміжки часу

Ми можемо вказати будь-який проміжок часу, за котрий нас цікавлять записи журналів. Лише необхідно враховувати часові формати. 

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

YYYY-MM-DD HH:MM:SS

Для прикладу, переглянемо всі записи, починаючи з 1 лютого 2025 г. 16:12 і до тепер:

$ journalctl --since "2025-02-01 16:12:00"

У якості ще одного часового формату можна використовувати англомовні назви часових одиниць. Їх можна вказати разом із опцією --since. Наприклад, переглянемо сьогоднішні записи:

$ journalctl --since today

Скористаємося розглянутими можливостями для вирішення більш складної ситуації.  Наприклад, ми отримали звіти про збої у роботі служби, котрі почалися у 10:00 та закінчилися 3 години тому. У цьому випадку нам допоможе наступна команда:

$ journalctl --since 10:00 --until "3 hour ago"

 

Так само можна вирішити будь-яке завдання, котре пов’язане із визначеним часовим проміжком.

Фільтрація за рівнем важливості повідомлень

У цьому разі можна виділити кілька основних покажчиків, за котрими можна робити вибірку даних:

За ідентифікатором процесу / групи / користувача;

• За програмними одиницями;

• За пріоритетом.

 Розглянемо процес використання кожного критерію.

За ідентифікатором

Як відомо, більшість служб створюють безліч дочірніх процесів, котрі отримують свій ідентифікатор PID. Саме його можна вказувати для отримання записів журналів по визначеному процесу. Для цього в команді необхідно вказати поле _PID.

Продемонструємо це. Але перед цим переглянемо ідентифікатори наявних у системі процесів за допомогою наступної команди:

$ ps -a

Припустимо, нас цікавить процес proxmox-datacen (PID=32966).

Переглянемо відповідні записи журналів:

$ journalctl _PID=32966

Ми також можемо переглянути всі доступні поля журналу для можливості використання їх у якості фільтруючих. Для цього введемо в терміналі:

$ man systemd.journal-fields 

Для того, щоб вивести записи того або іншого поля журнальної системи, необхідно скористатися опцією -F.

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

$ journalctl -F _GID

Отже, саме для виведених номерів груп ведуться записи в журнальній системі systemd. 

За програмними одиницями

Це один з найкорисніших варіантів фільтрації повідомлень. Для його «включення» слід вказати опцію -u у команді.

Для прикладу, переглянемо всі журнали програмної одиниці exim4 у нашій системі. Exim4 є агентом пересилання поштових повідомлень, або SMTP-сервером.

Введемо в терміналі:

$ journalctl -u exim4.service

Так само можна переглянути інформацію про будь яку запущену програму або службу.

За пріоритетом

Дуже часто з’являється потреба вивести записи із врахуванням рівня пріоритетності. Це дозволяє позбутися зайвої інформації та сконцентруватися лише на головному питанні. Для цього передбачена наявність опції -p. При її застосуванні будуть виведені повідомлення із вказаним або вищим пріоритетом.

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

$ journalctl -p crit -b

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

• 0 - emerg

• 1 - alert

• 2 - crit

• 3 - err

• 4 - warning

• 5 - notice

• 6 - info

• 7 - debug

Так, замість слова critical ми могли б вказати значення 3. Результат був би той самий.

Зміна формату відображення або виводу даних 

За рахунок зміни форматів відображення та / або виводу записів журналів можна отримати зручний інструмент маніпулювання даними. Можна виділити три основних напрямки:

• Урізання / розширення даних;

• Зміна виводу на «стандартний»;

• Зміна формату виводу. 

Урізання / розширення даних. Наприклад, якщо ми хочемо отримати усічений вивід, при якому на місці скороченої інформації будуть проставлені крапки, то необхідно використати опцію --no-full:

$ journalctl --no-full

І навпаки, якщо нам потрібно вивести всі дані, не приховуючи їх, потрібно скористатися опцією –a:

$ journalctl -a 

У такому разі будуть виведені абсолютно всі символи, включаючи і ті, котрі не друкуються.

Зміна виводу на «стандартний». За замовчуванням утиліта виводить дані у багатосторінковій панелі. Однак ми можемо відобразити їх усі разом, тобто, забезпечити їх «стандартний» вивід. Це можна зробити за допомогою опції --no-pager:

$ journalctl --no-pager 

Виведені записи одразу можна передати до текстового редактору або зберегти у вигляді файлу на диску.

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

Для прикладу, виведемо записи служби exim4 у форматі Json: 

$ journalctl -b -u exim4 -o json

Можна переконатися, що дані виведені у потрібному форматі. Однак, якщо ми плануємо у подальшому використовувати їх для проведення синтаксичного аналізу, то доцільно зробити структуру даних простішою. Зробимо це, змінивши формат на json-pretty:

$ journalctl -b -u exim4 -o json-pretty

 

Тепер ми отримали те, що хотіли – дані впорядковані та готові до подальшої обробки будь-якою утилітою для проведення синтаксичного аналізу.

Використання grep та awk для фільтрування записів

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

$ journalctl -u exim4.service | grep -i "error"

Опція -i тут використана для того, щоб включити примусове ігнорування регістру символів при написанні слова error.

На виході команди ми не отримали жодного повідомлення, оскільки помилки відсутні для цієї служби.

Тепер спробуємо вибрати записи лише двох полів журнальної системи – для часу та повідомлення. Введемо в терміналі:

$ journalctl -u exim4.service | awk '{print $3, $6}'

Можна переконатися, що ми отримали те, що хотіли.

Якщо ж нам потрібно зібрати записи про помилки за останні 10 годин у окремому файлі із ім’ям exim4_errors.log, то команда буде виглядати наступним чином:  

$ journalctl -u exim4.service --since "10 hour ago" | grep -i "error" | awk '{print $3, $6}' > /var/log/exim4_errors.log

Прибирання журналів

Вміст журналів можна оптимізувати за рахунок прибирання непотрібних нам символів або тегів. Для прикладу, видалимо інформацію, котра знаходиться у дужках []. Це можна зробити за допомогою потокового редактору sed:

$ journalctl -u exim4.service | sed 's/\[.*\]//g'

 

Можна переконатися, що зайва інформація видалена.

Підписуйтесь на наш телеграм-канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів.

Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

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

Швидкий та доступний vps хостинг від дата-центру FREEhost.UA це зручна панель керування, вигідні ціни та цілодобова технічна підтримка, а ще великий вибір шаблонів за якими можно автоматично створити сервер, безкоштовна панель керування, та 60 GB на сервері резервних копій.

Дата: 18.02.2025 Автор: Олександр Ровник #linux

Голосування 1 2 3 4 5