Продвинутые методы устранения неполадок в systemd journald

Отладка Linux-хоста на основе systemd часто начинается с журнала. journalctl -xe может показать недавние сбои, но настоящее устранение неполадок обычно требует сужения журналов по загрузке, временному диапазону, модулю, приоритету, процессу или исполняемому файлу.

Примеры ниже показывают, как превратить большой журнал в сфокусированное представление, которое можно использовать при сбоях служб, проблемах с загрузкой и повторяющихся системных ошибках.

Понимание журнала: структура и расположение

Журнал systemd объединяет журналы ядра, системных служб и приложений. В отличие от традиционных файлов syslog, журнал хранит записи в индексированном двоичном формате, что позволяет выполнять сложные запросы с помощью journalctl. Журналы обычно сохраняются в каталогах, таких как /var/log/journal/.

Ключевые концепции, которые следует запомнить:

Структурированное ведение журнала: Записи содержат поля метаданных (например, _PID, _COMM, _SYSTEMD_UNIT), которые journalctl использует для фильтрации.
Энергозависимое и постоянное хранение: Журналы могут храниться только в памяти (энергозависимое) или записываться на диск (постоянное). Конфигурация по умолчанию обычно отдает предпочтение постоянству.

Основные методы расширенной фильтрации

Мощь journalctl заключается в его способности сужать миллионы записей журнала. Вот наиболее эффективные расширенные фильтры.

1. Фильтрация по времени

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

A. Относительное время: Используйте -S (с) и -U (до) для указания относительного времени.

# Показать журналы за последние 30 минут
journalctl --since "30 minutes ago"

# Показать журналы между 10:00 вчера и сейчас
journalctl -S yesterday -U now

# Показать журналы за определенный временной диапазон (формат ISO 8601)
journalctl --since "2024-05-01 08:00:00" --until "2024-05-01 08:15:00"

B. Фильтрация по загрузке: Чтобы проанализировать конкретную проблемную последовательность загрузки, используйте флаг -b.

# Показать журналы только текущей загрузки
journalctl -b

# Показать журналы предыдущей загрузки
journalctl -b -1

# Показать журналы ядра за предпоследнюю загрузку
journalctl -b -2 -k

2. Фильтрация по модулю systemd и службе

Чтобы изолировать журналы, относящиеся к конкретной службе, используйте флаг -u или --unit. Это незаменимо при устранении неполадок сбоев служб.

# Показать все журналы для службы веб-сервера Apache
journalctl -u httpd.service

# Показать журналы для службы с момента последнего запуска
journalctl -u nginx.service --since "start of job -1"

3. Фильтрация по идентификатору процесса (PID) и имени исполняемого файла

Когда конкретный процесс аварийно завершается, но вы не сразу знаете, какой службе он принадлежит, фильтрация по PID или имени исполняемого файла (_COMM) очень эффективна.

# Показать журналы, связанные с конкретным идентификатором процесса (например, PID 4589)
journalctl _PID=4589

# Показать журналы для всех процессов с именем 'mysqld'
journalctl _COMM=mysqld

4. Фильтрация по уровню приоритета

Записям журнала присваиваются числовые приоритеты (0=emerg, 7=debug). Используйте флаг -p для фильтрации по серьезности, что помогает подавить избыточный вывод отладки при поиске ошибок.

Уровень приоритета	Ключевое слово	Числовое значение
Emergency	emerg	0
Alert	alert	1
Critical	crit	2
Error	err	3
Warning	warning	4
Notice	notice	5
Info	info	6
Debug	debug	7

# Показать только критические ошибки (уровень 2) и выше для системы
journalctl -p crit

# Показать все журналы, кроме отладочных сообщений
journalctl -p 6

Анализ сбоев загрузки и сообщений ядра

Устранение неполадок при запуске системы требует разделения сбоев служб пользовательского пространства и проблем инициализации ядра или оборудования.

Изоляция сообщений ядра (`-k` или `--dmesg`)

Флаг -k отображает только сообщения ядра (эквивалентно выполнению dmesg). Это важно для выявления проблем, связанных с драйверами устройств, распознаванием оборудования или сбоями ранней инициализации до того, как systemd загрузит службы.

# Просмотреть все сообщения ядра текущей загрузки
journalctl -k

# Поиск конкретных ошибок оборудования в журнале ядра предыдущей загрузки
journalctl -k -b -1 | grep -i "error"

Отслеживание зависимостей служб

Когда служба не запускается, это может быть связано с сбоем вышестоящей зависимости. Используйте обратное отображение (-r) в сочетании с фильтрацией модулей, чтобы увидеть последовательность, ведущую к сбою.

# Отобразить журналы для модуля в обратном хронологическом порядке
journalctl -u my-app.service -r

Расширенное форматирование вывода и экспорт

Для более глубокого анализа или обмена журналами важно изменить формат вывода.

1. Просмотр в формате JSON (`-o json`)

Для написания скриптов или интеграции с внешними инструментами анализа журналов предпочтителен структурированный вывод JSON.

journalctl -u sshd.service -o json

2. Просмотр в виде одной строки (`-o cat`)

Чтобы получить чистый, необработанный вывод без временных меток или метаданных (полезно при передаче непосредственно другим инструментам, таким как grep), используйте формат cat.

journalctl -u cron.service -o cat

3. Экспорт журналов

Чтобы архивировать или передавать журналы, экспортируйте их в стандартный текстовый файл. Если вам нужны определенные поля метаданных, выберите формат вывода, включающий структурированные поля.

# Экспортировать все журналы текущей загрузки в текстовый файл
journalctl -b > boot_log_$(date +%F).txt

# Экспортировать выбранные структурированные поля для одного модуля
journalctl -u mariadb.service -o json --output-fields=__REALTIME_TIMESTAMP,PRIORITY,_PID,_COMM,MESSAGE --since today > mariadb_recent.json