Логи на сервере: где искать и как читать

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

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

Два места, где живут логи

Файлы в каталоге /var/log. Классический способ: программа пишет в свой файл. Так ведут себя веб-серверы, почта, базы данных.

Системный журнал. Всё, что запущено службой, пишет в общий журнал, который читается отдельной командой. Отдельного файла у такой службы может не быть вовсе - и это первая причина, по которой логи не находят.

Правило простое: если сервис запущен как служба - смотрите журнал, если это отдельная программа - ищите файл.

Что где искать

Логи веб-сервера обычно лежат в /var/log/nginx/, там два файла: доступ и ошибки. Первый отвечает на вопрос кто приходил, второй - почему не получилось, см. Nginx на VPS.

Две команды, которых хватает

Смотреть файл в реальном времени:

tail -f /var/log/nginx/error.log

Строки появляются по мере записи. Открываете сайт в браузере, видите, что происходит в этот момент. Самый быстрый способ поймать ошибку.

Смотреть журнал службы:

journalctl -u имя-службы -n 50

Показывает последние 50 записей нужной службы. Полезные дополнения:

• -f - следить в реальном времени, как tail -f;
• --since "10 min ago" - только за последние десять минут;
• -p err - только ошибки, без обычных сообщений.

Искать по содержимому:

grep "error" /var/log/nginx/error.log | tail -20

Этого набора достаточно в подавляющем большинстве случаев.

Как читать запись

Строка лога почти всегда устроена одинаково: время, уровень важности, источник, сообщение.

Читать её стоит по трём вопросам:

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

Насколько серьёзно. Уровни идут от отладочных сообщений к критическим. Предупреждения в логах есть всегда и сами по себе ничего не значат - искать надо ошибки.

Что именно. Самая ценная часть - конкретика: какого файла не хватает, к какому адресу не удалось подключиться, какой пользователь получил отказ.

Практический приём: ищите первую ошибку, а не последнюю. Одна поломка порождает десятки следствий, и хвост лога обычно забит производными сообщениями, а причина лежит выше.

Три типовые ситуации

Ошибка 502. Веб-сервер не смог достучаться до приложения. Смотрите лог ошибок веб-сервера, а затем журнал самого приложения: почти всегда оно упало или не слушает нужный порт, см. порты на сервере.

Приложение не стартует. Журнал его службы покажет причину прямо в последних строках: не найден файл окружения, занят порт, нет прав на каталог.

Не пускает по SSH. Лог авторизации покажет, отклонён ли ключ, заблокирован ли адрес или дело в неверном пользователе. Заодно там видно, что вас перебирают боты - это нормальный фон, см. файрвол на VPS.

Почему логи однажды съедают диск

Одна из самых обидных аварий: место кончилось, сервисы встали, а причина - выросшие за месяцы логи.

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

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

Посмотреть, сколько места занято логами:

du -sh /var/log

Ограничить размер системного журнала:

journalctl --vacuum-size=500M

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

Что стоит помнить про содержимое

Логи веб-сервера содержат адреса посетителей и запрошенные страницы, а логи приложений иногда - и переданные данные. Отсюда два следствия.

Срок хранения выбирают осознанно. Держать год журналов доступа обычно незачем, а для персональных данных это ещё и вопрос требований закона, см. VPS в России.

Не логируйте лишнее. Пароли, токены и содержимое платёжных запросов не должны попадать в логи даже в отладочном режиме. Проверить это стоит до запуска, а не после.

Частые ошибки

Ищут файл там, где его нет. Служба пишет в системный журнал, а не в отдельный файл. Команда для них разная.

Смотрят конец лога вместо начала проблемы. Причина обычно выше, а хвост забит следствиями.

Читают лог доступа вместо лога ошибок. Первый отвечает кто приходил, второй - почему не получилось.

Не сверяют время. Сервер живёт в своём часовом поясе, и записи легко перепутать по времени.

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

Не следят за размером. Заполненный логами диск останавливает сервер надёжнее любой атаки.

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

Где лежат логи на сервере? В каталоге /var/log для программ, которые пишут в файлы, и в системном журнале для всего, что запущено службой. Логи веб-сервера обычно в /var/log/nginx/.

Как посмотреть логи в реальном времени? Командой tail -f для файла или journalctl -f -u имя-службы для журнала. Записи появляются по мере поступления.

Что смотреть при ошибке 502? Сначала лог ошибок веб-сервера, затем журнал приложения. Обычно оно упало или не слушает порт, к которому обращается веб-сервер.

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

Почему логи заняли весь диск? Отключена или не настроена ротация, слишком долгий срок хранения либо забытый отладочный режим. Проверить объём можно командой du -sh /var/log.

Сколько хранить логи? Столько, сколько нужно для разбора инцидентов, обычно недели или месяцы. Долгое хранение журналов доступа несёт риски по персональным данным.

Как найти конкретную ошибку в большом файле? Через grep по ключевому слову с ограничением вывода, либо в журнале через фильтр по уровню и периоду времени.

Нужен сервер, где логи ваши? VPS на NVMe с root-доступом - полный доступ к системному журналу и файлам, площадки в Москве, Казани и Амстердаме. Активация за 3 минуты, первые 7 дней - тестовый период с возвратом средств.