Навіщо розбиратися в логах 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.

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