Зачем разбираться в логах 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_addr | IP-адрес клиента |
| $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.