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

> Как настроить формат логов Nginx, включить ротацию через logrotate и разобрать access.log и error.log командами grep и awk.

## Зачем разбираться в логах 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](https://www.zevshost.net/ru/kb/nginx-502-504-diagnostika/), а для связки с PHP посмотрите [настройку Nginx и PHP-FPM](https://www.zevshost.net/ru/kb/nginx-php-fpm-svyazka/).

---

Источник: https://www.zevshost.net/ru/kb/nginx-logi-format-analiz/