Логи сайта: сбор и анализ логов доступа, ошибок и приложений
I. Каждый из трёх типов логов отвечает за своё — не смешивайте их
Многие сваливают все .log-файлы на сервере в одну кучу и при аварии перебирают их по одному. На самом деле три типа логов отвечают на три совершенно разных вопроса. Логи доступа (access.log в Nginx/Apache) отвечают на вопрос «кто, когда и что запросил»; логи ошибок (error.log в Nginx, ошибки PHP-FPM) — «где на сервере произошла ошибка»; логи приложения (log, который вы пишете в коде сами) — «на каком этапе обрабатывается заказ и почему не удалось».
Контринтуитивный вывод здесь такой:При аварии в продакшене меньше всего стоит начинать с логов доступа. Логи доступа объёмные и шумные — если смотреть их первыми, вы утонете в тысячах строк с кодом 200. Правильный порядок: сначала логи ошибок, чтобы найти точку сбоя, затем логи доступа, чтобы оценить масштаб (сколько пользователей, какие URL), и наконец логи приложения, чтобы восстановить ход бизнес-процесса. Это тот же подход, что и анализе логов AI-краулеров принцип «сначала разберись, кто тебя читает»: сначала классифицируй, потом анализируй.
| Тип лога | На какой вопрос отвечает | Типичное расположение | Рекомендуемый срок хранения |
|---|---|---|---|
| Логи доступа | Кто, когда и что запросил | Nginx access.log | 90 дней горячих данных |
| Логи ошибок | Где на сервере ошибка и почему | Nginx error.log / ошибки PHP | 1 год |
| Логи приложения | На каком этапе бизнес-процесс и где застрял | Пользовательский log в коде | 30 дней |
| Системные логи | События самого сервера | /var/log/messages | 30 дней |
II. Конвейер сбора: из «разбросанных по файлам» в «одно место для поиска»
Типичная ситуация для команды из одного человека: отдельный лог у Nginx, отдельный у PHP, отдельный пишет само приложение — всё в разных каталогах, и после перезагрузки сервера или переезда на другую машину история обрывается. Первый шаг в управлении логами — не анализ, а собрать их в одном месте.
Пайплайн состоит из четырёх этапов: приложение пишет файлы, ротация по дням, сбор в одном месте, алерты на ошибки. Для ротации используйте logrotate с ежедневной разбивкой и gzip-сжатием, иначе один файл на несколько гигабайт просто не откроется. Для сбора начните с простого: rsyslog или лёгкий агент отправляет логи на отдельную машину или в облачный сервис логирования.
Команде из одного человека не стоит сразу тащить тяжёлый стек вроде ELK — достаточно централизованного хранилища и поискового интерфейса, а о большем задумайтесь, когда объём вырастет. Для CDN-сайтов нужно собирать и edge-логи, и логи origin — подробнее об этом в Глобальное ускорение CDN.
| Этап | Как сделать | Инструмент / настройка | Что будет, если не сделать |
|---|---|---|---|
| Запись файлов | Единый формат вывода | Формат combined | Поля неполные, скрипты анализа писать сложно |
| Ротация | Ежедневная ротация со сжатием | logrotate | Один файл слишком большой, диск переполняется |
| Централизация | Сбор в одном хранилище | rsyslog / облачные логи | При смене машины история обрывается |
| Оповещения | Уведомление по порогу ошибок | Правила в системе мониторинга | О проблеме узнаёте только из жалоб пользователей |
III. Логи ошибок: за чем команде из одного человека следить в первую очередь
Из трёх типов логи ошибок дают больше всего информации на единицу объёма, и за ними стоит следить в первую очередь. В логах доступа — сотни тысяч строк в день, в логах ошибок — может быть всего несколько сотен, но каждая строка — это реальный сбой. Выделите логи ошибок в отдельное хранилище и настройте отдельные алерты — это даст максимальную отдачу.
Пороги задавайте конкретными числами: доля 5xx выше 1% в течение 10 минут подряд — алерт немедленно; единичная аномальная ошибка (например, сбой подключения к базе данных или сбой колбэка оплаты) — алерт при первом появлении, не дожидаясь накопления. Логи ошибок нужно разделять по уровням: warning просматривайте регулярно, error и critical требуют уведомления в реальном времени. В приложениях вроде PHP отдельно вылавливайте фатальные ошибки и медленные запросы.
Пример из практики: Однажды утром сработал алерт: доля 5xx подскочила с 0,1% до 3%. Сначала вы открываете логи ошибок и видите множество “PHP-FPM: unable to connect” — пул бэкенд-процессов переполнен. Затем по логам доступа смотрите, какие URL это вызвали, и обнаруживаете, что пул положил медленный запрос нового API. Наконец, по логам приложения определяете, какой именно это SQL. Локализация за десять минут — вот в чём ценность подхода, где логи ошибок идут первыми.
| Уровень ошибки | Пример | Что делать | Порог алерта |
|---|---|---|---|
| критично | База данных недоступна, оплата не прошла | Немедленное уведомление | Алерт при первом появлении |
| ошибка | 5xx, фатальные ошибки | Уведомление в реальном времени | > 1% за 10 минут |
| предупреждение | Медленные запросы, повторы | Ежедневный сводный просмотр | Сводка при превышении базовой линии в 2 раза |
| уведомление | Штатные бизнес-события | Архивировать без алертов | Без алертов |
IV. Логи приложения: сделайте бизнес-процессы отслеживаемыми
Логи доступа и ошибок — это “объективная” запись сервера, но они не отвечают на бизнес-вопросы вроде “почему этот лид не попал в CRM”. Здесь и нужны логи приложения — вы сами пишете их в ключевых точках бизнес-процесса: лид отправлен, записан в базу данных, передан в CRM, обратная передача из CRM не удалась.
Главное в логах приложения — чтобы каждая запись несла бизнес-идентификатор: ID заявки или номер заказа. Тогда при сбое вы ищете по этому ID и собираете весь путь сделки от отправки до завершения. Не пишите бессмысленные логи (“дошли до 10-й строки”) — каждая запись должна отвечать на бизнес-вопрос. Держите объём логов в пределах нескольких десятков МБ в день, не пишите тело запроса целиком: это и медленно, и раскрывает персональные данные.
Стоит упомянуть и связь производительности с логами: слишком много записей и синхронная запись на диск на каждом запросе сами по себе замедляют ответ. Как смотреть метрики медленных ответов, см.Core Web Vitals. Общая схема мониторинга и алертов — см.Мониторинг сайта и оповещения.
| Бизнес-этап | Что записывать | Идентификатор | Как искать при сбое |
|---|---|---|---|
| Отправка заявки | Поля формы, страница-источник | ID заявки | Поиск записи по ID |
| Запись в базу | Успешно / ошибка | ID заявки | Проверить, попала ли в базу |
| Отправка в CRM | Код ответа API, время выполнения | ID заявки | Проверить, приняла ли CRM |
| Уведомление по email | Успешно / ошибка | ID заявки | Проверить, получил ли менеджер |
Пять. Подводные камни: три самые частые ошибки в работе с логами
Первый камень — “не ротировать и не хранить”. Лог пишется в один файл, через три месяца это несколько гигабайт: grep при разборе зависает на полминуты, а то и диск забивается под ноль и сайт падает. Ротация по дням плюс политика хранения — это минимум.
Второй камень — “хранить только свежее, без архива”. Диск заполнился — удаляем самое старое, и когда нужно найти начало того сбоя двухмесячной давности, данных просто нет. Горячие данные храните 90 дней, просроченные сжимайте в архив минимум на год — это стоит копейки. Третий камень — “чувствительные данные в логах”. Пароли пользователей и полные номера карт в логах — это ещё один источник утечки в вашем лог-хранилище. Чувствительные поля маскируйте или не пишите на диск.
| Частая ошибка | Внешнее проявление | Реальная проблема | Как исправить |
|---|---|---|---|
| Без ротации | Файл растёт | Диск забит, поиск медленный | logrotate по дням |
| Без истории | Диск заполнился — удаляем | Нечего восстановить | Горячие 90 дней, архив 1 год |
| Чувствительные данные | Логи удобны для отладки | Лог-хранилище становится источником утечки | Маскировать чувствительные поля |
| Три типа в одной куче | При сбое перебирать всё подряд | Долгий поиск, много шума | Сначала ошибки, поиск по категориям |
FAQ: частые вопросы
Обязательно ли интернет-магазину ставить ELK?
Почему логи доступа, ошибок и приложения нельзя держать вместе?
Сколько хранить каждый тип логов?
Как задать пороги алертов для лога ошибок?
Насколько подробно писать лог приложения и не ударит ли это по производительности?
Можно ли писать в логи пароли и платёжные данные?
В заключение
Ценность управления логами не в том, «сколько накопили», а в том, «можно ли за три минуты найти причину при инциденте». Если вы ведёте сайт в одиночку, разделите три типа логов, настройте ежедневную ротацию с централизацией и алерт при доле ошибок выше 1% — с этой базой время на повседневный разбор упадёт с «полдня копания в логах» до «взглянуть на алерт». Тяжёлые платформы для логов — дело будущего, когда вырастете, а не обязательное условие на старте.
Три шага на практике. Первый: разделите логи доступа, ошибок и приложений по разным хранилищам и задайте для каждого свой срок хранения с ежедневной ротацией. Второй: соберите их в одном месте через rsyslog или облачный сервис логирования, чтобы можно было искать по бизнес-ID. Третий: настройте алерты — если доля ошибок за 10 минут превышает 1% или появилась хотя бы одна ошибка уровня critical. После этих трёх шагов вы перестанете узнавать о проблемах на проде от жалоб пользователей и начнёте узнавать о них первыми. Ритм обслуживания можно сверить с графиком обслуживания сайта и спланировать вместе.
Запомните одну фразу: логи — это не файлы на диске для ностальгии, а видеорегистратор места аварии. Если их не разложить по категориям и не собрать в одном месте, при инциденте останется только гадать по памяти.