Как анализировать логи Linux-сервера с помощью journalctl

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

1. Основные команды

Последние записи:
journalctl -n 100

Последние сообщения в реальном времени:
journalctl -fТекущая загрузка системы:
journalctl -bПредыдущая загрузка:
journalctl -b -1Список доступных загрузок:
journalctl --list-boots

Ошибки текущей загрузки:
journalctl -b -p err

Сообщения ядра:
journalctl -k

Ошибки и предупреждения:
journalctl -p warningПриоритеты журнала:

• 0 — emergency
• 1 — alert
• 2 — critical
• 3 — error
• 4 — warning
• 5 — notice
• 6 — info
• 7 — debug

Важно: наличие warning или error не всегда означает неисправность. Необходимо учитывать контекст и время появления сообщения.

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

При диагностике лучше ограничивать временной интервал, в котором возникла проблема.
journalctl --since "2026-09-12 10:00:00" --until "2026-09-12 11:00:00"

Последний час:
journalctl --since "1 hour ago"Последние 30 минут:
journalctl --since "30 minutes ago"Сообщения за сегодня:
journalctl --since todayЭто особенно важно при большом объёме логов.

3. Анализ конкретного сервиса

Для поиска проблем конкретного сервиса используется -u.
Например, Nginx:
journalctl -u nginxПоследние 100 сообщений:
journalctl -u nginx -n 100

За последний час:
journalctl -u nginx --since "1 hour ago"В реальном времени:
journalctl -u nginx -fДля SSH название unit зависит от дистрибутива:
journalctl -u ssh
journalctl -u sshdТакже можно проверить:
systemctl status nginx
systemctl --failedЕсли сервис находится в состоянии failed, его журнал обычно является первым местом для поиска причины.

4. Анализ SSH

При проблемах с подключением к SSH:
journalctl -u ssh --since "1 hour ago"

или:
journalctl -u sshd --since "1 hour ago"Для поиска ошибок авторизации:
journalctl -u ssh | grep -Ei "failed|authentication|invalid"В журнале можно обнаружить неудачные попытки входа, проблемы с ключами, неверные пароли и ошибки конфигурации.
При этом для некоторых систем дополнительные данные находятся в /var/log/auth.log или /var/log/secure.

5. Анализ неожиданной перезагрузки

Если сервер неожиданно перезагрузился, сначала определите предыдущую загрузку:
journalctl --list-bootsЗатем просмотрите конец предыдущей сессии:
journalctl -b -1 -eИ сообщения ядра:
journalctl -k -b -1Особое внимание стоит обратить на:
oom
panic
watchdog
I/O error
segfault
failed
error
Если в журнале нет явной причины, необходимо дополнительно проверить аппаратные логи, RAID, IPMI/iDRAC/iLO и другие доступные источники.

6. Поиск OOM Killer

При нехватке памяти Linux может принудительно завершить процессы через OOM Killer.
Поиск в журнале:
journalctl -k | grep -Ei "oom|out of memory|killed process"После обнаружения OOM следует проверить память:
free -hИ процессы, потребляющие больше всего RAM:
ps aux --sort=-%mem | head -20

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

7. Анализ дисков и файловой системы

Сообщения ядра о проблемах с дисками:
journalctl -k | grep -Ei "I/O error|read error|write error|nvme|ata|ext4|xfs"Для RAID можно дополнительно искать:
journalctl -k | grep -Ei "raid|md[0-9]|degrad"Однако journalctl не заменяет аппаратную диагностику. При подозрении на неисправность диска следует использовать:
smartctl, а для аппаратного RAID — инструменты соответствующего RAID-контроллера.

8. Анализ сетевых проблем

Сообщения ядра и сетевых сервисов:
journalctl -k | grep -Ei "network|link|eth|ens|eno|net"Для NetworkManager:
journalctl -u NetworkManagerДля systemd-networkd:
journalctl -u systemd-networkdМожно обнаружить события вроде:
Link is Down
Link is Up
Но journalctl не показывает полный маршрут сетевого трафика. Для дальнейшей диагностики используются:
ip -s link
ip route
ping
mtr
ss
tcpdump

9. Поиск конкретных сообщений

Для текстового поиска можно использовать grep:
journalctl -b | grep -i "error"Память:
journalctl -b | grep -Ei "oom|out of memory|killed process"Диски:
journalctl -k | grep -Ei "I/O error|nvme|ata|ext4|xfs"Сеть:
journalctl -k | grep -Ei "link is down|network|timeout"Также журнал можно фильтровать по PID или имени процесса:
journalctl _PID=1234
journalctl _COMM=nginx

10. Формат вывода

Для удобного отображения даты:
journalctl -o short-iso

Только текст сообщений:
journalctl -o cat

JSON:
journalctl -o jsonДля обычной диагностики достаточно стандартного формата или short-iso.

11. Если журнал занимает много места

Размер журнала:
journalctl --disk-usage

Настройки хранения:
cat /etc/systemd/journald.conf

Основные параметры:
SystemMaxUse=
SystemKeepFree=
MaxRetentionSec=
После изменения конфигурации:
systemctl restart systemd-journaldНе следует очищать или ограничивать журнал до завершения расследования, если старые записи ещё могут понадобиться.

12. Не ограничивайтесь journalctl

Не все приложения записывают сообщения непосредственно в systemd journal. Часть сервисов использует собственные файлы в /var/log/.
Например:
/var/log/syslog
/var/log/messages
/var/log/auth.log
/var/log/nginx/
/var/log/apache2/
Поэтому при расследовании необходимо проверять как journalctl, так и логи конкретного приложения.

Полезные команды

Задача	Команда
Последние 100 записей	journalctl -n 100
Новые сообщения в реальном времени	journalctl -f
Текущая загрузка	journalctl -b
Предыдущая загрузка	journalctl -b -1
Ошибки	journalctl -b -p err
Логи ядра	journalctl -k
Список загрузок	journalctl --list-boots
Логи сервиса	journalctl -u nginx
Логи сервиса за час	journalctl -u nginx --since "1 hour ago"
Failed-сервисы	systemctl --failed
Размер журнала	journalctl --disk-usage
Поиск по тексту	journalctl -b | grep -i "error"

Заключение

journalctl — один из основных инструментов диагностики Linux-сервера. Он позволяет определить, что произошло, когда это произошло и какой компонент системы был затронут.
Наиболее эффективный подход:
проблема → время события → journalctl → сервис/ядро → причина → дополнительная диагностика
Для полноценного анализа journalctl следует использовать вместе с systemctl, dmesg, top, free, iostat, ss, ip, mtr, tcpdump и логами конкретных приложений.