Как читать логи и находить причину сбоя

MAATRIX

Сайт упал, сервис не запускается, что-то работает не так — а причина непонятна. Разгадка почти всегда в логах: сервер и приложения подробно записывают, что с ними происходит, надо лишь знать, где смотреть и как читать. Ниже разберём по шагам, как читать логи и находить причину сбоя: где что лежит, какими командами искать и как двигаться от симптома к корню — с командами и практикой эксплуатации сервера.

Где лежат логи

Первое, что нужно знать, — куда смотреть. В современных системах на systemd есть два основных источника. Первый — системный журнал journald, куда пишут почти все службы; он читается командой journalctl. Второй — текстовые логи в каталоге /var/log: там лежат логи веб-сервера, базы данных, авторизации и многого другого. Знание этой карты экономит время: вместо паники вы идёте в конкретное место под конкретный симптом.

Разложим по задачам. Проблема с сервисом — смотрите journalctl для этого юнита. Ошибки сайта — логи веб-сервера, обычно в /var/log/nginx или /var/log/apache2. Проблема с базой — её лог в /var/log/mysql или через journalctl. Подозрение на взлом или неудачные входы — /var/log/auth.log. Ошибки приложения — его собственный лог, путь к которому задан в конфиге. Когда знаешь, где искать, полдела сделано.

Полезно с самого начала выработать правильный настрой при чтении логов, потому что новички часто совершают одну и ту же ошибку — пугаются объёма. В логе активного сервера тысячи строк, и большинство из них — обычные записи о нормальной работе, а вовсе не ошибки. Не пытайтесь прочитать всё подряд: это путь к панике и потере времени. Ваша задача не осилить весь лог, а найти в нём несколько релевантных строк вокруг момента сбоя. Поэтому чтение логов — это в первую очередь умение фильтровать: по времени, по сервису, по уровню важности, по ключевому слову. Хороший диагност не читает лог целиком, а быстро сужает его до десятка строк, которые относятся к делу. Освоив несколько приёмов фильтрации, вы перестаёте бояться больших логов и начинаете видеть в них не стену текста, а понятную хронику событий, из которой нужные записи выуживаются за минуту.

Читаем системный журнал

journalctl — главный инструмент диагностики на современных серверах. Чтобы посмотреть логи конкретного сервиса за последнее время, укажите юнит и период:

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

Ключ -u фильтрует по сервису, --since задаёт период, --no-pager выводит сразу без листалки. Для живого наблюдения за логом в реальном времени — когда вы воспроизводите проблему и хотите видеть, что происходит, — используйте флаг слежения:

journalctl -u myapp -f

Полезны и другие фильтры. Чтобы увидеть только ошибки и критичные сообщения по всей системе, отфильтруйте по приоритету, а чтобы посмотреть, что было при последней загрузке или падении, ограничьте вывод текущей загрузкой:

journalctl -p err -b --no-pager

Эти команды быстро сужают поток записей до тех, что действительно важны, вместо того чтобы вручную листать тысячи строк.

Читаем логи веб-сервера

Для проблем с сайтом главный источник — логи веб-сервера, и их два вида. Access-лог пишет каждый запрос и полезен, чтобы понять, что происходило в момент сбоя: какие URL долбили, был ли наплыв, откуда шёл трафик. Error-лог пишет собственно ошибки сервера и обычно ближе к корню проблемы. Смотрите свежие ошибки в конце файла:

tail -n 50 /var/log/nginx/error.log

Читайте ошибки осмысленно. Код 502 или 504 обычно значит, что упал или не отвечает бэкенд — приложение за веб-сервером. Код 500 — ошибка в самом приложении, ищите детали в его логе. Отказ в правах доступа указывает на неверные права на файлы. Каждая ошибка в error-логе — это подсказка, куда копать дальше, а не просто строка красного текста.

От симптома к причине

Читать логи мало — важно двигаться методично, а не хвататься за первое попавшееся сообщение. Начните с точного времени сбоя: когда именно перестало работать. Затем откройте логи нужного сервиса за этот момент и ищите первую аномалию по времени. Ключевой принцип — искать не последнюю ошибку, а первую в цепочке: часто одно исходное событие тянет за собой каскад следствий, и десяток красных строк — это эхо одной настоящей причины, случившейся чуть раньше.

Сопоставляйте источники. Если сайт отдал 502 в определённую секунду, посмотрите в этот же момент лог бэкенда — что случилось с приложением. Если приложение упало, посмотрите системный журнал — не убил ли его OOM-killer из-за нехватки памяти. Такое сопоставление логов по времени и есть настоящая диагностика: вы прослеживаете причинно-следственную цепочку от видимого симптома до исходного события. Полезный приём — грепать логи по времени или ключевому слову, чтобы быстро находить связанные записи в разных файлах.

Частые причины и что они дают в логах

Опыт подсказывает типовые сценарии, и знание их ускоряет поиск. Нехватка памяти оставляет в системном журнале следы работы OOM-killer с именем убитого процесса — ищите строки про killed process. Переполненный диск проявляется ошибками записи в самых разных сервисах разом, а подтверждается командой df. Падение бэкенда даёт в логе веб-сервера ошибки соединения с ним и коды 502/504. Ошибка в коде после деплоя — свежие исключения в логе приложения, начавшиеся ровно с момента выката. Атака или наплыв ботов видны в access-логе как всплеск запросов с подозрительных адресов.

Знание этих паттернов превращает чтение логов из гадания в узнавание: вы видите характерный след и сразу понимаете, что произошло. Это и есть зрелая эксплуатация сервера — умение по записям быстро восстановить картину сбоя.

Отдельно стоит позаботиться о том, чтобы логи вообще были на месте в нужный момент. Обидная ситуация — сбой случился, вы открываете логи, а там пусто или запись оборвалась ровно перед интересным моментом. Причины бывают разные: логи не писались из-за переполненного диска, слишком агрессивная ротация уже удалила нужный период, или уровень логирования был выставлен так, что важные события просто не фиксировались. Поэтому настройте логирование заранее, ещё до первого сбоя: разумный уровень детализации, достаточная глубина хранения, чтобы можно было заглянуть на несколько дней назад, и контроль за тем, чтобы диск не переполнялся и не рвал запись. Логи полезны ровно настолько, насколько они полны в момент, когда понадобились. А если логи раз за разом показывают одно и то же — нехватку ресурсов под нагрузкой, — значит сервер перерос тариф, и честнее добавить ресурсов: масштабировать VPS у MAATRIX можно без переезда, с оплатой из России картой или криптой.

Частые вопросы