Управление логами 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 по времени и типу

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

Чтобы увидеть сообщения, сгенерированные с момента последней загрузки, мы проверяем логи загрузки (boot logs) (записи событий, которые происходят в процессе запуска системы).

Выполните следующую команду:

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 минут.

Чтобы просмотреть логи ядра (kernel logs) (сообщения, генерируемые ядром 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: Фильтрация по приоритету

Каждая запись имеет приоритет (Priority) (уровень серьезности, присвоенный сообщению лога). Уровни варьируются от 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 может сильно увеличиться в размерах. Практика архивирования и удаления старых логов для экономии места называется ротацией логов (log rotation). Вы можете проверить, сколько места в настоящее время использует журнал 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
Владелец: Команда технической документации