Конспект раздела: эксплуатация

Раздел про жизнь конфига после того, как он написан.

Три темы

ИЗМЕНЕНИЯ      reload, worker_shutdown_timeout, reopen, замена бинарника
НАБЛЮДЕНИЕ     stub_status, три метрики, mirror и split_clients
ИНЦИДЕНТЫ      кто ответил → строка в логе → смягчение → починка

Что reload делает и чего не делает

Делает	Не делает
применяет конфиг и перечитывает имена бэкендов	не перерезолвит их сам между reload
поднимает новых воркеров	не чистит кеш ответов
не применяет битый конфиг	не сбрасывает счётчики лимитов
ждёт, пока старые доработают	не сообщает об ошибке применения

Последняя строка - главное, что стоит унести: при занятом порте reload возвращает ноль, сайт остаётся на старом конфиге, и правда лежит только в error_log. Старые воркеры ждут бесконечно (замер: живы и через семнадцать секунд), поэтому worker_shutdown_timeout.

Сигналы

HUP    reload            USR1   reopen
USR2   новый бинарник    WINCH  погасить воркеров
QUIT   плавно (100 байт из 100)   TERM  немедленно (40 из 100, ошибка у клиента)

USR2 требует запуска абсолютным путём - иначе execve() не найдёт бинарник.

Три метрики, которых достаточно

доля 5xx по $status;
$request_time против $upstream_response_time (перцентили, не среднее);
разница accepts и handled в stub_status - отброшенные соединения.

Слоты worker_connections тратятся на всё сразу: слушающий сокет, клиент и соединение к бэкенду. Замер: при значении 3 статика отдаётся, а проксируемый запрос даёт 500.

Дерево решений

меняешь конфиг?             → nginx -t && reload, потом смотреть error_log
меняешь версию nginx?       → пакет и рестарт; без простоя - вывод из балансировки
проверяешь новую версию?    → сначала mirror, потом split_clients долями
инцидент?                   → кто ответил → error_log → curl локально → бэкенд
плановые работы?            → файл-флаг и return 503, Retry-After с always

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

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; }     # режим обслуживания флагом

Чек-лист: что ты должен уметь объяснить

Что произойдёт с текущими запросами при reload и почему воркеры «висят».
Почему nginx -t может пройти, reload вернуть ноль, а конфиг не примениться.
Зачем нужен nginx -s reopen при ротации логов.
Чем QUIT отличается от TERM для клиента, который качает файл.
Что означает пустой $upstream_status, а что - 502 в нём же.
Почему медленное зеркало не задерживает клиента и чем оно всё же опасно.