Анализ логов в Linux: от базовых команд до продвинутых инструментов

Введение / Зачем это нужно

Логи (log-файлы) — это главный источник информации о том, что происходит внутри Linux-системы. Они содержат записи о работе ядра, системных служб, установленных приложений и событиях безопасности. Умение быстро находить и анализировать логи позволяет:

• Диагностировать сбои: Узнать, почему служба не запустилась, почему приложение упало.
• Отслеживать безопасность: Обнаружить подозрительные попытки входа (в auth.log).
• Мониторить производительность: Выявлять ошибки диска, проблемы с сетью.
• Аудит действий: Видеть, что делал пользователь или система в определённый момент.

Этот гайд проведёт вас от простого просмотра логов до эффективного поиска по сложным критериям.

Требования / Подготовка

Перед началом убедитесь, что:

1. У вас есть доступ к терминалу Linux (локально или по SSH).
2. Вы обладаете правами sudo (для просмотра всех логов systemd и файлов в /var/log/). Без sudo вы увидите только свои логи.
3. В системе используется systemd (подавляющее большинство современных дистрибутивов: Ubuntu, Debian, Fedora, CentOS/RHEL 8+). Проверить можно командой pidof systemd.
4. Базовое знакомство с командной строкой и командами cat, less, grep.

Шаг 1: Просмотр системного журнала с journalctl

journalctl — это основной инструмент для работы с Centralized Logging systemd. Он читает бинарный журнал, который агрегирует логи со всех служб и ядра.

Базовые команды:

# Просмотр всего журнала (сначала старые записи)
journalctl

# Просмотр с постраничным выводом (рекомендуется)
journalctl | less

# Слежение за логами в реальном времени (как tail -f)
journalctl -f

# Просмотр логов конкретной службы (unit)
journalctl -u ssh.service

# Просмотр логов за последние 2 часа
journalctl --since 2h

# Просмотр логов за сегодня
journalctl --since today

# Просмотр логов с определённого времени
journalctl --since "2026-02-15 09:00:00" --until "2026-02-15 10:00:00"

Ключи --since и --until принимают множество форматов: YYYY-MM-DD HH:MM:SS, yesterday, 1 hour ago.

Шаг 2: Фильтрация по уровню важности (приоритету)

Логи имеют уровни (facility) и приоритеты (priority). Чаще всего нужно искать ошибки.

# Показать только сообщения с уровнем ошибка (err) и выше (crit, alert, emerg)
journalctl -p err

# Тот же результат, но с явным указанием диапазона
journalctl -p err..crit

# Показать только предупреждения (warning)
journalctl -p warning

# Полный список уровней: emerg, alert, crit, err, warning, notice, info, debug.

Шаг 3: Поиск по ключевым словам и контексту

Команда journalctl поддерживает встроенные фильтры, но часто удобнее использовать grep.

# Поиск упоминаний "failed" (регистрозависимый)
journalctl | grep failed

# Поиск без учёта регистра
journalctl | grep -i timeout

# Поиск строк, содержащих "error" или "Exception"
journalctl | grep -E "error|Exception"

# Показать 5 строк до и после совпадения (контекст)
journalctl | grep -C 5 "segmentation fault"

# Поиск в конкретном файле лога (не в journald)
grep -i "authentication failure" /var/log/auth.log

Шаг 4: Работа с классическими лог-файлами в /var/log/

Не всё попадает в systemd journal. Многие приложения пишут в собственные текстовые файлы в /var/log/.

Основные файлы:

• /var/log/syslog или /var/log/messages — общие системные сообщения.
• /var/log/auth.log или /var/log/secure — аутентификация, sudo, ssh.
• /var/log/kern.log — логи ядра.
• /var/log/dmesg — вывод dmesg на момент загрузки.
• /var/log/apt/history.log — история установки пакетов (Debian/Ubuntu).

Команды для работы:

# Просмотр последних 50 строк syslog
tail -n 50 /var/log/syslog

# Постоянный мониторинг файла
tail -f /var/log/auth.log


# Поиск в старом архивированном файле (например, syslog.1)
zcat /var/log/syslog.1.gz | grep "service started"

# Поиск по нескольким файлам
grep "connection refused" /var/log/nginx/error.log /var/log/syslog

Шаг 5: Анализ логов конкретных служб и приложений

SSH-подключения:

journalctl -u ssh.service
# или
grep "sshd" /var/log/auth.log | tail -50

Nginx/Apache:

# Обычно логи в /var/log/nginx/ или /var/log/apache2/
tail -f /var/log/nginx/error.log
grep "404" /var/log/nginx/access.log | wc -l  # количество 404 ошибок

Cron (планировщик):

# Логи cron обычно в syslog или в отдельном файле
grep CRON /var/log/syslog

Упавшие службы (systemd):

# Посмотреть статус и последние логи службы
systemctl status <service_name>
journalctl -u <service_name> --since "5 min ago" -p err

Критические ошибки ядра (dmesg):

dmesg | tail -50
dmesg | grep -i "memory\|error\|fail"

Шаг 6: Продвинутый анализ: статистика и агрегация

Часто нужно понять не просто что произошло, а какие события самые частые.

# Топ-10 источников логов (по PID/имени) в journalctl за последний час
journalctl --since 1h --no-pager | awk '{print $5}' | sort | uniq -c | sort -nr | head -10

# Количество ошибок по типам (пример для syslog)
grep -o -E "error|fail|exception" /var/log/syslog | sort | uniq -c | sort -nr

# Поиск всех попыток brute-force в ssh (много неудачных логинов)
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr

Шаг 7: Сохранение и экспорт логов для глубокого анализа

Если нужно отправить логи разработчику или проанализировать в другом инструменте:

# Экспорт журнала systemd за последние сутки в текстовый файл
journalctl --since yesterday > /tmp/journal_$(date +%F).txt

# Экспорт с ограничением по размеру (например, 50 МБ)
journalctl --since "1 day ago" --output=short-monotonic > /tmp/last_day.log

# Создание сжатого архива логов из /var/log/ (требует sudo)
sudo tar -czf /tmp/logs_archive_$(date +%F).tar.gz /var/log/

Проверка результата

Вы успешно освоили анализ логов, если можете:

1. Быстро найти причину падения службы: journalctl -u <service> -p err --since "10 min ago" показал ошибку.
2. Отследить подозрительную активность: grep "Failed password" /var/log/auth.log выявил IP-адрес атакователя.
3. Увидеть, что загрузило систему: journalctl -b (логи текущей загрузки) и поиск по kworker или oom-killer.
4. Сформировать отчёт: Экспортировали логи за определённый период в файл.

Возможные проблемы

Проблема: journalctl выводит "No journal files were found." Решение: Служба systemd-journald не работает или журнал отключён. Проверьте systemctl status systemd-journald. Возможно, логи пишутся только в /var/log/.

Проблема: Permission denied при чтении /var/log/ или journalctl. Решение: Запускайте команды с sudo или от имени root. Для journalctl можно добавить пользователя в группу systemd-journal (sudo usermod -aG systemd-journal $USER), но это даёт доступ ко всем логам.

Проблема: Логи ротируются (переименовываются в .gz), а grep не находит старые записи. Решение: Используйте zgrep для сжатых файлов или разверните их zcat/gunzip -c.

Проблема: Слишком много логов, ничего не разобрать. Решение: 1. Ужесточите фильтрацию (-p err, конкретная служба, конкретное время). 2. Используйте --no-pager для вывода в stdout и перенаправьте в файл для анализа в редакторе. 3. Ищите уникальные PID или UID и анализируйте логи только от них. 4. Настройте более гранулярное логирование в конфигурации приложения (например, loglevel = WARN вместо DEBUG).