Конспект: разбор инцидентов

Разбор инцидента: от кода в мониторинге до причины в логе.

Сначала - кто ответил

log_format timing '$status ups_status=[$upstream_status] ups_addr=[$upstream_addr] '
                  'rt=$request_time urt=[$upstream_response_time]';

Прочерк в $upstream_status означает, что к бэкенду не обращались: ответил return, статика, лимит, кеш (HIT) или error_page без обращения к бэкенду (если error_page обработал ошибку бэкенда, его код в переменной остаётся). Отказ в соединении переменную заполняет - замер даёт 502 вместе с адресом бэкенда.

Код → причина

Таблица - частые причины и что проверить, а не доказательства: один и тот же код дают разные поломки, причину называет строка в error_log.

Код	Частая причина	Что проверить
502	соединения не было или ответ негоден; сюда же `no live upstreams`; бывает 502 самого бэкенда	жив ли процесс, строки `upstream` в логе
504	бэкенд не уложился в таймаут соединения или ответа	этап в строке `upstream timed out`, медленные запросы
503	сработал свой лимит; 503 шлёт и бэкенд на обслуживании	зоны лимитов, строка `limiting requests`, `$upstream_status`
500	у прокси - кончились слоты `worker_connections`; или приложение, или ошибка конфига	`[alert]` в `error_log`, `$upstream_status`
499	клиент ушёл, не дождавшись	почти всегда следствие медленного бэкенда
413	тело больше `client_max_body_size`	загрузка файлов
414 / 400	длинный URI или заголовок	`large_client_header_buffers`
429	твой `limit_req_status`	зоны лимитов

Строки error_log дословно

Строка	Причина
`connect() failed (111: Connection refused)`	бэкенд не слушает порт
`upstream timed out (110) ... reading response header`	не ответил за таймаут, клиент получит 504
та же строка без слова header	код ответа уже ушёл: клиент получит его (обычно 200) с обрезанным телом
`upstream sent too big header`	не хватает `proxy_buffer_size`
`no live upstreams`	все серверы группы помечены недоступными, клиенту 502
`[alert] ... worker_connections are not enough while connecting to upstream`	слота не нашлось, клиенту 500
`[warn] ... worker_connections are not enough, reusing connections`	nginx закрыл keepalive и справился
`[crit] accept4() failed (24: ...)`	кончились дескрипторы процесса, а не слоты

Слова системной ошибки зависят от libc (Operation timed out против Connection timed out), номер - нет. Искать в логах надо по номеру.

Первые пять минут

1. жив ли процесс и слушает ли порт
2. что в конфиге на диске: nginx -T; применён ли - reload в error_log и запрос
3. свежие строки error_log (всё, что сыплется неделями, - фон)
4. воспроизвести локальным curl с нужным Host
5. проверить бэкенд напрямую тем же путём

Смягчения, которые готовят заранее

proxy_cache_use_stale error timeout http_500 http_502 http_503;   # отдать старое
error_page 502 503 504 /50x.html;                                 # честная страница
if (-f /etc/nginx/maintenance.on) { return 503; }                 # режим работ флагом

Замер заглушки: файл создан - 503 без reload, файл удалён - снова 200. Условие проверяется на каждом запросе.

Ловушки джокера

Retry-After без always на странице заглушки не отдаётся: add_header по умолчанию работает только на успешных кодах и редиректах, а заглушка - это 503.
Чинить 499 на стороне nginx - это клиент ушёл; смотреть надо на бэкенд.
Поднимать таймауты вместо разбора: удержанные соединения съедают слоты, и через полчаса получишь второй инцидент, уже свой.
Крутить буферы и воркеров на горячую: эффект не отличить от случайных колебаний, а объяснить улучшение потом не выйдет.
Считать, что «нет ошибок в логе» значит «всё хорошо»: обрыв после заголовков и отброшенные соединения в access_log не видны вовсе.