Як експортувати журнальні логи systemd за допомогою journalctl

Запустіть journalctl з вікном часу та -o json, і отримайте один об’єкт JSON на рядок з усіма полями, які журнал зберіг:

sudo journalctl --since "2026-10-19 00:00" --until "2026-10-20 00:00" -o json --no-pager > web-03_journal.jsonl

Для текстового файлу в стилі syslog замість цього використовуйте -o short-iso. Без sudo або членства в systemd-journal, adm або wheel ви бачитимете лише свій власний журнал користувача, а не системний.

На більшості сучасних дистрибутивів журнал – це місце, куди все потрапляє спочатку: служби, ядро, sudo, cron, входи. На Debian 12 і пізніших версіях, Fedora та Arch, це часто є єдиним місцем, тому що rsyslog не встановлено. Prime Core має {N} правил виявлення для журналів системи Linux, прив’язаних до {M} технік MITRE ATT&CK, серед яких стійкість cron (T1053.003), шкідливі служби systemd (T1543.002) та зловживання sudo (T1548.003).

Почніть безкоштовно

Перш ніж розпочати

Дозволи. Ті ж правила, що й для будь-якого системного журналу: root або вищезазначені групи. Наш [Посібник з дозволів журналів Linux] має деталі.

Чи виживає журнал після перезавантаження? Якщо /var/log/journal не існує, журнали зберігаються в пам’яті в /run/log/journal та зникають при перезавантаженні. journalctl –list-boots показує, скільки у вас справжніх завантажень. Якщо вказує лише поточну, то стара історія зникла.

Скільки є? journalctl –disk-usage повідомляє вам перед тим, як ви все це вивантажите у файл. За замовчуванням, постійний журнал може дорости до 10% свого файлової системи, обмежено до 4 ГБ. Це набагато більше, ніж ви хочете завантажити одразу.

Часові зони. Журнал зберігає позначки часу в UTC, але journalctl друкує місцевий час, якщо не додати –utc. Вивід JSON несе сиру позначку часу в мікросекундах UTC (__REALTIME_TIMESTAMP) в обох випадках.

Крок 1: Звужте пошук

Виберіть фільтри, що відповідають вашому запитанню. Вони поєднуються:

Крок 2: Вибір формату виводу

• -o json: один об’єкт JSON на рядок, з усіма полями. Це основний вибір для LogTotal, тому що нічого не втрачається.
• -o json –output-fields=MESSAGE,_HOSTNAME,_COMM,_PID,SYSLOG_IDENTIFIER,PRIORITY: те саме, але скорочено. Декілька полів, таких як позначки часу та ID завантаження, завжди включені. Це значно зменшує розмір файлу.
• -o short-iso: текст у стилі syslog з повними позначками часу в ISO. Менший і легкий для читання неозброєним оком. [ПІДТВЕРДЖЕННЯ: підтвердьте, що LogTotal аналізує short-iso]

Не використовуйте -o export. Незважаючи на назву, це формат серіалізації для відправки журналів між машинами systemd, а не для аналізу.

Рекомендуємо вам типовий експорт з обмеженим обсягом:

sudo journalctl -b -1 -p info -u ssh -u cron 

  -o json --no-pager > web-03_prevboot.jsonl

Крок 3 (необов’язково): Читати файли журналів з іншої машини

У роботі з інцидентами часто є образ диска або скопійована папка /var/log/journal, а не жива система. journalctl читає їх безпосередньо:

journalctl -D /mnt/evidence/var/log/journal -o json --no-pager > evidence_journal.jsonl

Використовуйте –file для вказівки на окремі файли .journal. Журнал з аварійно завершеної або неохайно вимкненої системи може показати попередження про пошкодження. Більшість записів зазвичай все одно доступні.

Завантажте, дезінфікуйте та перевірте в LogTotal

1. Завантажте. Відкрийте logtotal.com і завантажте файл .jsonl. [ПІДТВЕРДЖЕННЯ: екран завантаження, обмеження за розміром]
2. Дезінфікуйте. [PROOF: what gets masked in journal JSON: hostnames, usernames, IPs, machine and boot IDs]. Look it over before you continue.
3. Перегляньте. [PROOF: what the results screen shows]

Як це виглядає на реальних даних. Ми експортували день журналу з [ПІДТВЕРДЖЕННЯ: джерело зразка, наприклад, непотрібна тестова VM після додавання cron-завдання, нового користувача та підозрілої служби systemd]. LogTotal відзначив [ПІДТВЕРДЖЕННЯ: реальні знахідки]. [ПІДТВЕРДЖЕННЯ: посилання на файл зразка]

Коли щось йде не так