К основному содержимому

Логи Nginx: формат access_log, ротация и разбор ошибок

Nginx · 29.09.2026

Зачем разбираться в логах Nginx

Логи Nginx — первое место, куда стоит смотреть при любой проблеме: медленный сайт, ошибка 502, подозрительный всплеск трафика. По умолчанию сервер пишет два файла: /var/log/nginx/access.log с каждым запросом и /var/log/nginx/error.log с ошибками воркеров и бэкенда.

Без настройки формата и ротации логи быстро превращаются в бесполезную свалку: диск заполняется, а найти нужную строку среди миллионов записей невозможно.

Формат access_log: что означают поля

Стандартный формат combined задан в nginx.conf, но его стоит расширить полем времени ответа:

log_format extended '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'rt=$request_time uct=$upstream_connect_time urt=$upstream_response_time';

access_log /var/log/nginx/access.log extended;
ПеременнаяЧто содержит
$remote_addrIP-адрес клиента
$statusКод ответа: 200, 404, 502 и так далее
$request_timeПолное время обработки запроса Nginx
$upstream_response_timeВремя ответа PHP-FPM или другого бэкенда

Поле rt — самое полезное для диагностики: если request_time большой, а upstream_response_time маленький, тормозит сам Nginx или сеть, а не приложение.

Как настроить ротацию логов

На Ubuntu и Debian ротацию логов Nginx обычно делает logrotate через конфигурацию /etc/logrotate.d/nginx:

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

Сигнал USR1 заставляет Nginx переоткрыть файлы логов без перезапуска воркеров — иначе после переименования файла запись продолжится в удалённый inode, а новый файл останется пустым.

Как быстро найти нужное в access.log

Частые запросы для разбора логов — без специальных инструментов, только grep и awk:

  • все запросы с кодом 502 за сегодня: grep " 502 " access.log
  • топ-10 IP-адресов по числу запросов: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10
  • запросы дольше 2 секунд: awk '$NF+0 > 2 {print}' access.log
  • количество запросов по кодам ответа: awk '{print $9}' access.log | sort | uniq -c

Что искать в error.log

Файл error.log пишет проблемы воркеров: ошибки конфигурации, обрывы соединений с бэкендом, превышение таймаутов. Уровень логирования задаёт директива error_log /var/log/nginx/error.log warn; — для продакшена уровня warn достаточно, debug включают только на время диагностики: он создаёт огромный объём записей.

Строки вида upstream timed out и connect() failed указывают на проблему бэкенда, а не самого Nginx — это повод проверить PHP-FPM или прокси-сервер.

Хранение и анализ в масштабе

Если сайтов и серверов несколько, ручной разбор логов через ssh перестаёт работать. Логи стоит отправлять в централизованное хранилище: syslog, Loki или Elasticsearch, — а на самом сервере хранить только последние 14 дней, чтобы не забивать диск.

Итог

Чек-лист по логам Nginx:

  • расширить log_format полями request_time и upstream_response_time
  • настроить logrotate с сигналом USR1 для переоткрытия файлов
  • держать error_log на уровне warn в продакшене
  • искать медленные и ошибочные запросы через awk и grep, прежде чем звать разработчика

Если в логах регулярно встречаются коды 502 и 504, разберите отдельно причины в статье диагностика 502 Bad Gateway и 504 Gateway Timeout, а для связки с PHP посмотрите настройку Nginx и PHP-FPM.

← Назад в базу знаний Задать вопрос поддержке