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

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

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

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

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

Код → причина

Код	Что произошло	Куда смотреть
502	соединения не было или ответ негоден; сюда же `no live upstreams`	жив ли процесс, строки `upstream` в логе
504	бэкенд принял и не ответил вовремя	`proxy_read_timeout`, медленные запросы
503	сработал свой лимит	зоны лимитов, строка `limiting requests`
500	кончились слоты `worker_connections`	`[alert]` в `error_log`
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
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 не видны вовсе.