stub_status и три метрики, которые нужны

Метрики уже собираешь - листай до второго разбора: там про то, сколько соединений съедает один проксируемый запрос.

worker_connections 3. Статика отдаётся нормально, а тот же сайт через proxy_pass отвечает 500. Опечатки в конфиге нет, бэкенд жив. Что происходит?

worker_connections 2: свой ответ=000, через прокси=000
worker_connections 3: свой ответ=200, через прокси=500
worker_connections 4: свой ответ=200, через прокси=200

На что это похоже

worker_connections привычно читают как «сколько клиентов поместится». На самом деле это число слотов на всё сразу: слушающий сокет занимает слот, клиент занимает слот, и соединение к бэкенду занимает ещё один - как будто в приёмной считают не посетителей, а стулья, и один стул всегда занят вешалкой, а переговорщик с поставщиком садится на второй.

Отсюда правило, которое экономит вечер: делить настроенное число пополам, если сайт проксирующий. И отсюда же понятно, почему nginx с worker_connections 2 вообще не стартует.

Механизм: что считает stub_status

Правило

location = /nginx_status {
    stub_status;

    allow 127.0.0.1;
    allow 10.0.0.0/8;
    deny  all;

    access_log off;
}

Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106

Закрывать обязательно: секретов тут нет, но профиль нагрузки виден, а сама страница удобна как цель для опроса чужими руками. access_log off - чтобы опросы раз в секунду не забивали лог.

Разбор: работает ли keepalive

Вопрос «а keepalive-то у нас включён?» решается двумя замерами. Двадцать запросов одним соединением и двадцать - каждый своим:

Отношение requests / accepts в первом случае около десяти, во втором - около единицы. Единица означает, что каждый запрос платит за установку соединения, а на HTTPS ещё и за рукопожатие; на графике это видно как ровная линия, которая не должна быть ровной.

Замерить это на живом сервере - минута, а вывод серьёзный: если отношение близко к единице, ищи, кто обрывает keepalive - клиент, промежуточный прокси или твой же keepalive_timeout 0.

Разбор: сколько соединений съедает один запрос

Тот же стенд, что в крючке, только теперь с логом:

Читается так. Слушающий сокет забирает слот ещё до первого клиента - поэтому при двойке nginx честно отказывается стартовать:

nginx: [emerg] 1 worker_connections are not enough for 1 listening sockets

При тройке хватает на сокет и клиента, но не на соединение к бэкенду - и клиент получает 500, а не 502 и не 503. Это важное различие: 500 в такой ситуации означает не ошибку приложения, а нехватку ресурсов у самого nginx. В логе рядом лежит объяснение, и уровень у него alert, а не warn:

[alert] 10#10: *10 4 worker_connections are not enough while connecting to upstream,
  client: 127.0.0.1, server: , request: "GET /apislow/x HTTP/1.1"

Хвост строки называет и место: слот кончился при подключении к бэкенду, а не при приёме клиента.

Что ломается без этого

Наплыв, которого не видно в кодах ответа. Стенд с worker_connections 4 и тридцатью параллельными запросами: accepts 38, handled 31. Семь соединений были приняты ядром и отброшены nginx - клиент увидел обрыв, а в access_log для них нет ни строки, потому что запроса не случилось. Единственные следы - расхождение двух чисел в stub_status и [alert] в error_log. Если снимать только «долю 5xx по логу», такой инцидент не виден вовсе.

Телеметрия, которую никто не проверял. Метрика, собираемая не с той машины или не в том формате, выглядит как здоровый график. Проверяется нарочной поломкой:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/этого-точно-нет

В графике должен появиться 404. Не появился - разбираться сейчас, а не в три часа ночи. Так же проверяются и алерты: подними порог на минуту и убедись, что письмо дошло. Ненастроенный алерт хуже отсутствующего - он создаёт ложное чувство безопасности.

Зачем это в работе

Три показателя, которых stub_status не даёт и которые снимаются из лога: доля 5xx ловит поломки, 95-й процентиль $upstream_response_time ловит деградацию до того, как она станет поломкой, число 499 ловит терпение пользователей - оно кончается раньше любых твоих таймаутов.

log_format metrics '$time_iso8601 $status $request_time $upstream_response_time '
                   '$upstream_cache_status $upstream_addr';

Разбирать этот формат можно чем угодно - от awk до экспортера в Prometheus. Важно не чем, а что рядом с ним лежит опрос stub_status: коды ответа и счётчики соединений отвечают на разные вопросы, и инцидент, который не видно в одном, обычно виден в другом. В открытой версии активных проверок здоровья бэкендов нет, их роль играют пассивные max_fails и fail_timeout из восьмого раздела.

Теперь сам

В мониторинге ровная линия: requests растёт примерно так же, как accepts, их отношение около единицы. Жалоб нет, ошибок нет. Стоит ли что-то делать?