Введение / Зачем это нужно
journalctl — это мощная утилита для просмотра и анализа системного журнала systemd, который заменяет традиционные файлы логов (например, /var/log/syslog). С её помощью вы можете:
- Диагностировать сбои: найти причину, почему служба не запустилась или упала.
- Анализировать производительность: отслеживать загрузку системы, запросы к службам.
- Безопасность: проверять подозрительные события (неудачные логины, изменения).
- Мониторинг: следить за работой в реальном времени.
Этот гайд превратит вас из новичка, который знает только journalctl | grep error, в уверенного пользователя, способного быстро находить нужную информацию.
Требования / Подготовка
- Операционная система: Любой современный Linux-дистрибутив с systemd (Ubuntu 20.04+, Debian 10+, CentOS 8+, Fedora 35+ и др.).
- Права доступа: Для просмотра всех логов нужны права root или членство в группе
systemd-journal. Обычные пользователи видят только свои логи.- Добавиться в группу:
sudo usermod -aG systemd-journal $USER(требуется перелогин).
- Добавиться в группу:
- Базовые знания: Уверенное использование терминала, понимание, что такое systemd-службы (
.service).
💡 Совет: Если вы работаете на сервере без графического интерфейса,
journalctl— ваш основной инструмент диагностики. Знание его фильтров сэкономит часы поиска.
Пошаговая инструкция
Шаг 1: Базовый просмотр логов
Просто запустите journalctl — вы увидите весь журнал, начиная с самого раннего. Это аналог cat /var/log/syslog, но с возможностью фильтрации.
journalctl
По умолчанию используется пейджер less. Навигация:
Space— следующая страница.b— предыдущая страница.q— выход.
Важно: Если вывод слишком большой, сразу применяйте фильтры (см. ниже).
Шаг 2: Фильтрация по времени
Часто нужно посмотреть логи за последние несколько часов или дней. Используйте:
-S(--since) — начальное время.-U(--until) — конечное время.
Формат времени гибкий:
# Логи за сегодня
journalctl --since today
# За последние 2 часа
journalctl --since "2 hours ago"
# За конкретный день (с 00:00 до 23:59)
journalctl --since "2026-02-14" --until "2026-02-15"
# С точностью до минуты
journalctl --since "2026-02-14 09:30:00" --until "2026-02-14 10:00:00"
Шаг 3: Фильтрация по службе (юниту)
Если проблема связана с конкретной службой (например, nginx, docker), фильтруйте по её имени:
journalctl -u nginx.service
Краткая форма: journalctl -u nginx (расширение .service необязательно).
Можно комбинировать с временными фильтрами:
journalctl -u docker.service --since "1 hour ago"
Шаг 4: Поиск по приоритету (уровню логирования)
Журнал systemd классифицирует сообщения по приоритетам (от самого критичного до отладочных):
| Приоритет | Код | Пример |
|---|---|---|
| emerg | 0 | Система неработоспособна |
| alert | 1 | Требуется немедленное действие |
| crit | 2 | Критические ошибки |
| err | 3 | Ошибки (по умолчанию для -p err) |
| warning | 4 | Предупреждения |
| notice | 5 | Обычные, но значимые события |
| info | 6 | Информационные сообщения |
| debug | 7 | Отладочная информация |
Фильтр по уровню:
# Только ошибки и выше (err, crit, alert, emerg)
journalctl -p err
# Все, кроме debug (info и выше)
journalctl -p info
# Только предупреждения
journalctl -p warning
Шаг 5: Мониторинг в реальном времени
Чтобы видеть новые записи по мере их появления (как tail -f), используйте флаг -f:
journalctl -f
Комбинации:
- С фильтром по службе:
journalctl -u ssh.service -f - С фильтром по приоритету:
journalctl -p err -f - С фильтром по времени (покажет новые записи после указанного времени):
journalctl -S "10:00" -f
Шаг 6: Поиск по тексту и регулярным выражениям
Для поиска внутри записей используйте grep-подобные флаги:
-kили--dmesg— показать только сообщения ядра (аналогdmesg).-g <pattern>— поиск по регулярному выражению (требует systemd ≥ 237).
# Поиск слова "failed"
journalctl | grep failed
# Более эффективно: journalctl умеет фильтровать сам
journalctl -g "failed to start"
# Поиск по IP-адресу (регулярное выражение)
journalctl -g "192\.168\.1\.\d+"
Шаг 7: Просмотр логов других пользователей и загрузочных сообщений
- Логи загрузки:
journalctl -b(текущая загрузка),journalctl -b -1(предыдущая загрузка). - Логи конкретного юнита за загрузку:
journalctl -u ssh.service -b. - Логи указанного PID:
journalctl _PID=1234. - Логи указанного исполняемого файла:
journalctl /usr/bin/nginx.
Шаг 8: Управление размером журнала (очистка)
По умолчанию journal может занимать много места (до 10% от диска). Управление:
- Просмотр текущего использования:
journalctl --disk-usage - Очистка старых записей:
# Удалить записи старше 7 дней journalctl --vacuum-time=7d # Оставить не более 500M journalctl --vacuum-size=500M # Удалить все логи (осторожно!) journalctl --rotate && journalctl --vacuum-time=1s - Настройка постоянных лимитов (см. раздел «Возможные проблемы»).
Проверка результата
После выполнения шагов вы должны уметь:
- Найти ошибку службы:
journalctl -u nginx.service -p err --since "10 minutes ago"
Вывод должен содержать строки сFailedилиerror. - Отследить загрузку системы:
journalctl -b -1 -p warning
Покажет предупреждения предыдущей загрузки (полезно при проблемах с загрузкой). - Контролировать размер:
journalctl --disk-usage
Значение должно быть разумным (например, < 500M на сервере).
Если вы можете выполнить эти три пункта — гайд освоен.
Возможные проблемы
Проблема 1: «No journal files were found» или пустой вывод
Причина: Журнал отключен или хранится только в оперативной памяти (параметр Storage=volatile в /etc/systemd/journald.conf).
Решение:
- Проверьте конфиг:
cat /etc/systemd/journald.conf | grep Storage. - Если
Storage=volatile, измените наpersistent(хранить на диске). - Перезапустите:
sudo systemctl restart systemd-journald.
Проблема 2: Недостаточно прав для просмотра логов
Причина: Текущий пользователь не в группе systemd-journal.
Решение: Добавьте пользователя в группу и перелогиньтесь:
sudo usermod -aG systemd-journal $USER
newgrp systemd-journal # или перезайдите в терминал
Проблема 3: Журнал занимает весь диск
Причина: Нет настроенных лимитов, логика ротации не сработала. Решение:
- Немедленно очистите:
sudo journalctl --vacuum-size=100M. - Настройте лимиты в
/etc/systemd/journald.conf:[Journal] SystemMaxUse=500M SystemKeepFree=1G MaxRetentionSec=30d - Перезапустите
systemd-journald.
Проблема 4: Нельзя найти нужную запись из-за огромного объема логов
Решение: Всегда используйте комбинацию фильтров! Например:
# Ошибки nginx за последние 30 минут
journalctl -u nginx -p err --since "30 minutes ago"
# Все записи, связанные с сетью, за сегодня
journalctl -g "network" --since today
Проблема 5: Хочу видеть логи в классических файлах (/var/log/syslog)
Причина: По умолчанию systemd может дублировать логи в /var/log/syslog (через systemd-journald → rsyslog), но это настраивается.
Решение: Убедитесь, что rsyslog установлен и настроен на принятие сообщений из journal. Обычно это работает «из коробки» в Debian/Ubuntu. Для чистого journal-only дистрибутивов (например, некоторые версии Fedora) классические файлы могут отсутствовать.
Проблема 6: Нужно сохранить логи для отправки разработчикам
Решение: Экспортируйте в текстовый файл с фильтрацией:
journalctl -u myapp.service --since "2026-02-14" > myapp_logs.txt
Или в бинарном формате (для полной совместимости):
journalctl --output=export -u myapp.service > myapp_logs.journal
Проблема 7: journalctl тормозит при большом объеме логов
Решение: Используйте --no-pager для отключения less, или сразу фильтруйте:
journalctl --no-pager -u nginx -p err --since "1h"