Урок 70: Логи как инструмент расследования.

Цель урока: Перейти от простого чтения логов к расследованию инцидентов. Мы освоим контекстный поиск (grep), научимся фильтровать события по времени в journalctl и связывать ошибки ядра с поведением приложений.

Мы работаем от root.

Часть 1: Теория. Два мира логов

В современном Linux (Ubuntu 20.04/22.04) логи живут в двух параллельных мирах:

1. Текстовые файлы (/var/log/): Старая школа. Это обычные файлы, которые можно открыть в nano или читать cat.

   • syslog: Обо всём понемногу.

   • auth.log: Кто входил, кто вводил неправильный пароль, кто делал su.

   • nginx/error.log: Ошибки веб-сервера.

2. Journald (бинарные логи): Новая школа. Система systemd перехватывает вывод всех служб и сохраняет их в специальном формате.

   • Доступ только через команду journalctl.

   • Плюсы: Можно мгновенно фильтровать по времени, службе и критичности.

Золотое правило администратора:
Если проблема в конкретной программе (Nginx, MySQL) - смотрим её текстовый лог.
Если проблема системная (не стартует сервис, ошибка диска, сетевой сбой) - смотрим journalctl.

Часть 2: Мастерство Grep (Контекстный поиск)

Обычный grep "error" file.log часто бесполезен. Он показывает строку с ошибкой, но не показывает, что случилось за секунду до неё.

Допустим, мы ищем, почему падает MySQL.

Плохой способ:

grep "Error" /var/log/mysql/error.log

Результат: [Error] Shutdown complete. (Ну выключился и выключился, непонятно почему).

Профессиональный способ (Контекст):
Используйте ключи -B (Before), -A (After) или -C (Context).

# Показать строку с ошибкой + 5 строк ДО неё
grep -B 5 "Error" /var/log/syslog

Практика:
Попробуйте найти входы в систему через SSH, но с контекстом (кто это был):

grep -C 2 "Accepted password" /var/log/auth.log

Вы увидите не только факт входа, но и соседние события (открытие сессии).

Часть 3: Journalctl - машина времени

Когда сервер упал "вчера ночью", листать миллион строк бесполезно. Нам нужно точное временное окно.

Сценарий: Клиент жаловался, что сайт не работал сегодня с 10:00 до 10:30 утра.

1. Фильтр по времени:

journalctl --since "today 10:00" --until "today 10:30"

2. Фильтр по конкретной службе:
Нам не интересны логи почты, если упал Nginx.

journalctl -u nginx --since "1 hour ago"

3. Фильтр по уровню серьёзности (Priority):
Логи делятся на уровни: Info, Warning, Error, Critical.
Чтобы не видеть мусор ("Инфо: пользователь нажал кнопку"), покажем только ошибки:

journalctl -p err -b

• -p err: Только ошибки и хуже.

• -b: Только с момента последней загрузки (Boot). Очень полезно, чтобы не смотреть ошибки прошлого месяца.

Часть 4: Логи ядра (dmesg vs journalctl -k)

Ядро Linux (Kernel) - это "нижний этаж". Если сгорает диск, сбоит сетевая карта или приходит OOM Killer (из Урока 66), об этом пишет ядро.

Есть команда dmesg. Она показывает "буфер сообщений ядра".
Проблема dmesg: По умолчанию она показывает время в секундах от включения ([ 1234.5678] Error...). Это неудобно.

Правильный способ 1 (dmesg с датами):

dmesg -T

(Флаг -T переводит секунды в человеческую дату).

Правильный способ 2 (через journalctl):

journalctl -k -b

Это покажет логи ядра (-k) с момента текущей загрузки (-b) с нормальной навигацией и поиском (нажмите /, чтобы искать).

Кейс расследования:
Если сервер внезапно перезагрузился сам по себе, первое, что вы делаете после включения:

journalctl -k -b -1 -p err

• -b -1: Покажи логи предыдущей загрузки (до перезагрузки).

• -p err: Покажи только ошибки.
  Если там пусто - возможна аппаратная проблема (питание, reset, watchdog) или резкий power loss.

Часть 5: Наблюдение в реальном времени (tail -f)

Когда вы что-то настраиваете и хотите видеть реакцию сразу.

Для текстовых файлов:

tail -f /var/log/auth.log

(Попробуйте в другом окне открыть новую SSH-сессию, и вы увидите строки в реальном времени).

Для systemd служб:

journalctl -u nginx -f

(Флаг -f означает Follow - следовать).

Трюк для профи: Мульти-лог
Иногда нужно видеть логи сразу двух сервисов (например, WordPress и MySQL), чтобы понять связь.
В journalctl это просто:

journalctl -u mysql -u nginx -f

Вы увидите сообщения от обоих сервисов в одном потоке, хронологически. Это лучший способ отладки связки "Сайт + База".

Часть 6: Логи занимают всё место? (Очистка)

Логи journalctl могут разрастись до гигабайтов.
Проверим, сколько они весят:

journalctl --disk-usage

Если там слишком много (например, 4 ГБ), можно безопасно почистить:

# Оставить только последние 500 Мб
journalctl --vacuum-size=500M

# ИЛИ оставить только последние 2 дня
journalctl --vacuum-time=2d

Для текстовых файлов (/var/log) за очистку отвечает утилита logrotate. Она запускается автоматически раз в сутки, архивирует старые логи и удаляет совсем древние. Обычно её трогать не надо, она настроена по умолчанию.

Итоги урока

Теперь вы не просто читатель, вы следователь.

1. Контекст - король. Используйте grep -C 5, чтобы видеть, что привело к ошибке.

2. Время - фильтр. Используйте journalctl --since, чтобы сузить круг поиска.

3. Связи. Используйте journalctl -u сервис1 -u сервис2 -f, чтобы видеть взаимодействие компонентов.

4. Ядро. Если сервер "умер" молча, смотрите journalctl -k -b -1 (логи ядра за прошлую сессию).

В Уроке 71 мы проведем финальный аудит безопасности. Мы возьмем утилиты Lynis и chkrootkit и просканируем сервер на наличие дыр в безопасности, вирусов и закладок хакеров. Это будет генеральная уборка перед выпуском в продакшн.

Перейти к просмотру - УРОК №71.