Введение / Зачем это нужно
Системные логи в Linux — это главный источник информации о работе операционной системы, служб и приложений. При возникновении ошибок (сбой службы, проблемы с сетью, аппаратные сбои) первым делом нужно обратиться к логам. Это руководство поможет вам освоить основные инструменты для просмотра, фильтрации и анализа логов, что значительно ускорит диагностику проблем.
Что вы получите:
- Умение быстро находить логи systemd с помощью
journalctl. - Навык работы с текстовыми логами в
/var/log/. - Понимание различий между журналом systemd и классическим syslog.
- Способность фильтровать логи по времени, сервису, уровню важности.
Требования / Подготовка
Перед началом убедитесь, что:
- У вас есть доступ к терминалу Linux (локально или через SSH).
- Для чтения системных логов обычно требуются права sudo (особенно для
journalctlи файлов в/var/log/). - Ваша система использует systemd (проверьте командой
systemctl). Если systemd нет, работайте только с текстовыми логами в/var/log/. - Базовые навыки работы с командной строкой: навигация, использование
grep,less,tail.
Шаг 1: Основы работы с journalctl (systemd-журнал)
Большинство современных дистрибутивов (Ubuntu, Fedora, CentOS 8+) используют systemd-journald для сбора логов. Этот журнал хранится в бинарном формате и доступен через утилиту journalctl.
Просмотр всех логов
sudo journalctl
Эта команда выведет все записи журнала с начала загрузки. Используйте стрелки для прокрутки, / для поиска внутри less, q для выхода.
Просмотр последних записей
sudo journalctl -n 50 # последние 50 строк
sudo journalctl -f # следить за логом в реальном времени (как tail -f)
Фильтрация по времени
sudo journalctl --since "2026-02-16 09:00:00" --until "2026-02-16 10:00:00"
sudo journalctl --since 1h # за последний час
sudo journalctl --since today
Фильтрация по сервису
sudo journalctl -u sshd.service # логи службы SSH
sudo journalctl -u nginx.service
Фильтрация по уровню важности (приоритету)
Уровни: emerg, alert, crit, err, warning, notice, info, debug.
sudo journalctl -p err # только ошибки
sudo journalctl -p warning..err # от warning до err включительно
Просмотр логов за текущую загрузку
sudo journalctl -b # текущая загрузка
sudo journalctl -b -1 # предыдущая загрузка
Поиск по тексту
sudo journalctl | grep -i "failed" # поиск слова "failed" (без учета регистра)
sudo journalctl | grep -i "error\|fail" # несколько паттернов
Шаг 2: Работа с классическими текстовыми логами (/var/log)
Если ваша система не использует systemd или вам нужны логи конкретных приложений, смотрите файлы в /var/log/.
Основные файлы логов
/var/log/syslog(Debian/Ubuntu) — общий системный лог./var/log/messages(RHEL/CentOS/Fedora) — аналогично syslog./var/log/kern.log— логи ядра./var/log/auth.log(Debian) //var/log/secure(RHEL) — аутентификация, SSH, sudo./var/log/dmesg— вывод dmesg при последней загрузке.
Просмотр и мониторинг
sudo tail -f /var/log/syslog # следить за обновлениями
sudo less /var/log/auth.log # просмотреть с навигацией
sudo grep "sshd" /var/log/auth.log # найти упоминания sshd
Ротация логов
Файлы в /var/log/ часто сжимаются и ротируются (например, syslog.1, syslog.2.gz). Для просмотра сжатых файлов:
zcat /var/log/syslog.2.gz | less
Шаг 3: Использование dmesg для логов ядра
Команда dmesg показывает кольцевой буфер ядра Linux. Полезна для диагностики аппаратных проблем, ошибок драйверов, загрузки.
Просмотр буфера ядра
sudo dmesg
sudo dmesg | less # с пагинацией
Фильтрация по подсистеме
sudo dmesg | grep -i usb # USB-устройства
sudo dmesg | grep -i eth # сетевые интерфейсы
sudo dmesg | grep -i error # ошибки ядра
Мониторинг в реальном времени
sudo dmesg -w # следить за новыми сообщениями ядра
Сохранить вывод в файл
sudo dmesg > dmesg_output.txt
Шаг 4: Логи конкретных приложений и служб
Многие сервисы пишут логи в собственные файлы в /var/log/. Обычно это каталог с именем сервиса.
Примеры:
- Nginx/Apache:
/var/log/nginx/access.log,/var/log/nginx/error.logsudo tail -f /var/log/nginx/error.log - MySQL/MariaDB:
/var/log/mysql/error.logsudo cat /var/log/mysql/error.log | grep -i "error" - Docker:
/var/log/docker.logилиdocker logs <container_id>docker logs --tail 100 контейнер_имена
Поиск логов неизвестного сервиса
ls -la /var/log/ # посмотреть структуру
sudo find /var/log -name "*<имя_сервиса>*" -type f # найти файлы по шаблону
Шаг 5: Расширенные техники фильтрации и поиска
Комбинируйте инструменты для точного поиска.
Поиск по дате в текстовых логах
sudo grep "Feb 16" /var/log/syslog # искать по дате (формат зависит от локали)
Использование journalctl с grep
sudo journalctl | grep -i "failed to start" # найти конкретную фразу
Экспорт журнала systemd в текстовый файл
sudo journalctl > full_journal.txt
Просмотр логов с цветовым выделением
Установите ccze или используйте:
sudo journalctl --no-pager | ccze -A
Шаг 6: Настройка ротации и очистки логов
Очистка старого журнала systemd
# Оставить записи только за последние 2 дня
sudo journalctl --vacuum-time=2d
# Ограничить размер журнала 500 МБ
sudo journalctl --vacuum-size=500M
Настройка journald (конфиг /etc/systemd/journald.conf)
[Journal]
SystemMaxUse=500M # максимальный размер журнала
MaxRetentionSec=1week # хранить не дольше недели
После изменений перезапустите: sudo systemctl restart systemd-journald.
Настройка logrotate для текстовых логов
Конфиги в /etc/logrotate.d/. Пример для nginx:
/var/log/nginx/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 640 www-data adm
sharedscripts
postrotate
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
endscript
}
Проверка результата
После выполнения шагов вы должны:
- Увидеть последние записи журнала systemd через
journalctl -xe. - Найти логи конкретного сервиса (например,
journalctl -u sshdили/var/log/auth.log). - Отфильтровать логи по времени или уровню ошибки.
- При необходимости очистить старые записи, чтобы освободить место.
Пример проверки: Выполните sudo journalctl -p err --since "1 hour ago". Если команда возвращает записи (или пустой вывод, если ошибок нет) — инструмент работает.
Возможные проблемы
❌ "Failed to connect to bus: No such file or directory" при journalctl
Причина: systemd-journald не запущен или вы не в системе с systemd (например, в контейнере).
Решение: Проверьте systemctl status systemd-journald. В контейнерах используйте текстовые логи в /var/log/.
❌ "Permission denied" при чтении логов
Причина: Недостаточно прав.
Решение: Добавьте sudo или добавьте пользователя в группу adm (Debian/Ubuntu) или systemd-journal (RHEL):sudo usermod -aG adm $USER (требуется перелогин).
❌ Логи /var/log/syslog пустые или отсутствуют
Причина: Возможно, используется systemd-journald без прямого вывода в файл, или syslog-демон не настроен.
Решение: Проверьте, работает ли systemd-journald. Для сохранения логов в файл настройте systemd-journald или установите rsyslog.
❌ Журнал systemd слишком большой
Причина: По умолчанию journald может занимать много места.
Решение: Настройте ограничения в /etc/systemd/journald.conf (см. Шаг 6) и выполните sudo journalctl --vacuum-size=200M.
❌ Не могу найти логи конкретного приложения
Причина: Приложение может писать логи в свой каталог (например, /opt/app/logs/) или в journald.
Решение: Проверьте документацию приложения. Используйте sudo journalctl | grep -i "имя_приложения" или найдите файлы: sudo find / -name "*app*log*" 2>/dev/null.
Заключительные рекомендации
- Приоритет: Начинайте с
journalctl -xe— это самый быстрый способ увидеть последние ошибки systemd. - Фильтрация: Всегда сужайте вывод по времени (
--since), сервису (-u) или уровню (-p). Это сэкономит время. - Мониторинг: Для отслеживания событий в реальном времени используйте
journalctl -fилиtail -f /var/log/syslog. - Документация: Конкретные приложения (PostgreSQL, Docker, Kubernetes) часто имеют свои каталоги логов — изучайте официальную документацию.
- Безопасность: Не оставляйте старые логи на диске бесконечно. Настройте ротацию, особенно на production-серверах.
Эти навыки помогут вам перестать "гадать" при ошибках и быстро находить корень проблемы. Удачи в диагностике