Введение / Зачем это нужно
Логи (journal) в Linux — это главный источник информации о том, что происходит в системе. Они содержат записи от ядра, системных служб и приложений. Умение быстро находить в них нужные данные — ключевой навык для диагностики сбоев, анализа безопасности и мониторинга производительности. После этого гайда вы сможете не просто "смотреть логи", а целенаправленно искать причины проблем.
Требования / Подготовка
- Доступ к терминалу Linux (Ubuntu, CentOS, Debian или другой дистрибутив с systemd).
- Права sudo (администратора) для чтения большинства системных логов. Без них вы увидите только записи, связанные с вашим пользователем.
- Базовое знакомство с командной строкой (навигация, запуск команд).
- Понимание, какая служба или процесс вызывает проблему (например, веб-сервер не запускается, сеть не поднимается).
Шаг 1: Начните с systemd journal (journalctl)
Современные дистрибутивы Linux используют systemd-journald для централизованного сбора логов. Это самый мощный и удобный инструмент.
Основные команды для начала:
# Показать все логи системы (сначала самые свежие)
sudo journalctl
# Показать логи только за текущую загрузку системы
sudo journalctl -b
# Фильтрация по конкретной службе (например, ssh)
sudo journalctl -u ssh.service
# Логи с уровнем ошибка (err) и выше (crit, alert, emerg)
sudo journalctl -p err
# Логи за определённый период
sudo journalctl --since "2024-01-15 09:00:00" --until "10:30"
sudo journalctl --since 1h # за последний час
sudo journalctl --since today
# Следить за логами в реальном времени (аналог tail -f)
sudo journalctl -f
💡 Совет: Комбинация флагов — ваша главная сила. Пример: sudo journalctl -u nginx --since '10 minutes ago' -p warning покажет предупреждения и ошибки nginx за последние 10 минут.
Шаг 2: Работа с классическими текстовыми логами в /var/log
Хотя journalctl доминирует, многие приложения (особенно сторонние или в контейнерах) пишут в отдельные текстовые файлы в /var/log/.
Ключевые директории и файлы:
/var/log/syslogили/var/log/messages— общие системные события./var/log/auth.logили/var/log/secure— логи аутентификации (ssh, sudo, login)./var/log/kern.log— сообщения ядра./var/log/nginx/,/var/log/apache2/— логи веб-серверов./var/log/dmesg— буфер сообщений ядра (аналогdmesg).
Основные команды для работы с текстовыми логами:
# Просмотр последних строк файла (как tail)
sudo tail -n 50 /var/log/syslog
# Поиск по шаблону (регистрозависимо)
sudo grep "failed" /var/log/syslog
# Поиск с игнорированием регистра
sudo grep -i "error" /var/log/auth.log
# Поиск по нескольким файлам
sudo grep "connection" /var/log/nginx/*.log
# Просмотр в реальном времени
sudo tail -f /var/log/syslog
# Поиск с контекстом (3 строки до и после совпадения)
sudo grep -A 3 -B 3 "segfault" /var/log/kern.log
Шаг 3: Используйте мощные инструменты для сложного анализа
Для глубокого анализа полезны утилиты, работающие как с выводом journalctl, так и с текстовыми файлами.
awk — для извлечения полей
Логи часто имеют структурированный формат (дата, время, уровень, сообщение). awk позволяет работать с колонками.
# Из journalctl вывести только время и сообщение, отфильтровав по PID
sudo journalctl -o short-iso | awk '$5 == "1234" {print $1, $2, $3}'
# Из текстового лога посчитать, сколько раз встречается конкретная ошибка
sudo grep "No space left on device" /var/log/syslog | awk '{print $1}' | sort | uniq -c
less + поиск — для интерактивного изучения
Для больших файлов используйте less (или sudo less /var/log/syslog). Внутри less:
/— начать поиск (например,/timeout).n/N— следующее/предыдущее совпадение.&— фильтровать вывод по шаблону (все строки, НЕ содержащие шаблон, скрываются).F— режим слежения (какtail -f).
journalctl в качестве источника для других утилит
Вывод journalctl можно передавать в grep, awk и т.д.
# Найти все записи, содержащие слово 'firewall', и сохранить их
sudo journalctl | grep -i firewall > firewall_issues.log
# Сортировать логи по PID и посмотреть уникальные процессы
sudo journalctl -o json | jq -r '_processID' | sort | uniq
(Примечание: для работы с -o json и jq может потребоваться установка пакета jq)
Шаг 4: Сохраните и экспортируйте важные данные
Для долгосрочного анализа или отправки в поддержку нужно сохранить логи.
# Экспорт логов конкретной службы за последние 2 часа в файл (формат journalctl)
sudo journalctl -u sshd --since 2h > sshd_last_2h.log
# Экспорт в стандартизированный текстовый формат (с временными метками)
sudo journalctl -u nginx --since yesterday --no-pager > nginx_yesterday.txt
# Создание сжатого архива логов для отправки
sudo journalctl --since 2024-01-01 --until 2024-01-07 | gzip > logs_jan1-7.txt.gz
Шаг 5: Настройте логирование (профилактика)
Чтобы избежать ситуаций, когда логи забивают диск, настройте ротацию (удаление старых логов) и уровень детализации.
Для systemd-journald:
Отредактируйте /etc/systemd/journald.conf:
[Journal]
# Ограничить общий размер журнала
SystemMaxUse=500M
# Ограничить размер одного файла журнала
SystemMaxFileSize=50M
# Хранить логи не дольше 2 недель
MaxRetentionSec=2week
# Уровень детализации (info, debug, warning...). Для продакшена оставьте info или warning.
# MaxLevelStore=info
Примените изменения: sudo systemctl restart systemd-journald.
Для классических логов (logrotate):
Логи в /var/log обычно управляются демоном logrotate. Его конфигурация находится в /etc/logrotate.conf и /etc/logrotate.d/. Стандартные настройки обычно адекватны.
Проверка результата
Вы успешно научились анализировать логи, если можете:
- Найти последние ошибки для конкретной службы (например,
sudo journalctl -u docker --since 1h -p err). - Отфильтровать логи по времени и уровню критичности.
- Сохранить релевантный фрагмент логов в файл для дальнейшего использования.
- Понять, откуда брать логи для нового приложения (обычно это либо journalctl, либо файл в
/var/log/<appname>/).
Возможные проблемы
Проблема: "Permission denied" при чтении логов
Причина: Вы запускаете команду без sudo.
Решение: Всегда используйте sudo для чтения системных логов (/var/log/*, journalctl). Если sudo недоступен, можно добавить пользователя в группу adm (sudo usermod -aG adm $USER), но это требует перелогина.
Проблема: В journalctl пусто или нет записей за определённый период
Причина 1: Журнал мог быть очищен (journalctl --vacuum-size).
Причина 2: Слишком агрессивные настройки MaxRetentionSec в journald.conf.
Решение: Проверьте настройки хранения. Для постоянного архивирования критичных логов настройте их дублирование в отдельный текстовый файл через конфигурацию службы (например, StandardOutput=syslog или file в юните systemd).
Проблема: Слишком много данных, ничего не найти
Причина: Запрос слишком общий или уровень логирования слишком низкий (debug).
Решение: Усильте фильтрацию. Добавьте временные рамки (--since, --until), конкретную службу (-u) и уровень (-p). Если нужно, временно повысьте уровень логирования для службы, чтобы увидеть детали, но помните о последующем возврате к info/warning.
Проблема: Логи приложения пишутся в неизвестное место
Причина: Приложение может быть настроено на логирование в свой файл в /var/log/ или в стандартный вывод (stdout/stderr), который systemd перехватывает.
Решение: 1) Проверьте документацию приложения. 2) Найдите процесс (ps aux | grep <app>) и посмотрите его аргументы запуска. 3) Проверьте юниты systemd (systemctl status <app>.service), там может быть указан StandardOutput=journal или file. 4) Используйте sudo lsof -p <PID> | grep log, чтобы увидеть открытые файлы дескриптора процесса.
Продвинутый пример: поиск причины падения сети
Допустим, сеть периодически отключается.
- Определите временное окно: Когда было последнее падение? (
uptime, история команд). - Проверьте ядро и сетевые службы:
sudo journalctl -b -k | grep -i "network\|eth\|link" # логи ядра за текущую загрузку sudo journalctl -u systemd-networkd --since "2 hours ago" sudo journalctl -u NetworkManager --since "2 hours ago" - Проверьте аутентификацию (если проблема с SSH):
sudo grep "Failed password" /var/log/auth.log | tail -20 - Проверьте системные сообщения:
sudo journalctl --since "2 hours ago" -p warning..err | grep -E "(network|connection|timeout|reset)" - Сопоставьте с другими событиями: Возможно, падение совпадает с запуском другого сервиса (
sudo journalctl --since "2 hours ago" | grep "Started"), ротацией логов или cron-задачей.
Заключение (не добавляем как отдельный заголовок)
Анализ логов — это практический навык, который развивается с опытом. Начните с простых команд journalctl -u <service> -f и grep по /var/log/. Со временем вы научитесь быстро комбинировать фильтры, понимать типичные паттерны ошибок и проводить_root cause analysis_ (анализ первопричины). Помните: логи почти всегда говорят правду, если умеешь их читать.