# Логи 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/uk/kb/nginx-502-504-diagnostika/), а для зв'язки з PHP подивіться [налаштування Nginx і PHP-FPM](https://www.zevshost.net/uk/kb/nginx-php-fpm-svyazka/).

---

Джерело: https://www.zevshost.net/uk/kb/nginx-logi-format-analiz/