Ничего такого нет(

ребята, есть фронт nginx, есть кучка nginx бэкендов, и периодически на фронте возникает ошибка
no live upstreams while connecting to upstream  
которая длится 30-60 секунд и потом пропадает.
думал что возникает изза того что бэкенды вгружаются и не успевают отвечать, но ошибка может возникнуть как в 8 вечера (пик нагрузки), так и в 3-4 ночи (минимум нагрузки)... в чем может быть подвох?

периодически возникает еще и
upstream prematurely closed connection while reading response header from upstream

может быть выполняется какой-нибудь длинный запрос (запросы?) на бэкэндах, который не укладывается в read timeout на nginx?

да запросы там в основном простые - за статикой.
если бы апстримы не успевали отвечать - было бы 504 gateway timeout, но браузерам отдается именно 502 bad gateway...
да и колво запросов у нас огромное, поэтому если бы что-то сильно тупило - это было бы все время, а тут внезапно возникает, длится секунд 30-60, и дальше работает как ни в чем не бывало...

может быть keepalive timeout как раз соблюдается, а вот upstream read нет? а ещё, во время факапов апстримы реально недоступны или nginx, например, просто не смог открыть соединение? (max open files закончилось, или что-то типа)

а вот хз :) отловить проблему сложно. возникнуть она может в любое время, и длится непродолжительное время. зайти на фронт/бэк само собой не успеешь

а что бы ты сделал, если бы зашёл? прикрути скрипт с этими командами и в крон :) а метрики с хостов собираются? что статистика говорит?

а хз что бы сделал. метрики всякие собирает заббикс, но там нет никаких заметных проседаний во время проблем...

и в статистике с бэкэндов тоже нет аномалий?

а известны конкретные урлы с ошибками? там нет каких-нибудь закономерностей? или всё разные файлы?

еще действительно проверь всякие лимиты и нет ли ошибок на интерфейсах, например

да, все нормально. урлы все разные, а ошибки на интерфейсах надо проверить

я таки нашел причину внезапной 502й ошибки. в общем, никогда не пытайтесь на бэкенде нестандартным http-статусом... есть дефолтный вхост в котором было return 444, которое валилось в логи и анализировалось в дальнейшем для автоматического забана и как оказалось что nginx с таким кодом ничего не отдает (даже http заголовков) и ничего не пишет в лог.
и получалось что в различные периоды времени прилетала пачка некорректных запросов (ну, пытаются проверить можно ли заюзать как прокси), которые улетали на бэкенды и с бэкендов возвращалось ничего, поэтому фронт помечал все бэкенды поочереди как недоступные и начинали валиться 502 Bad Gateway :)

дадада, про 444 правда. в своё время пришлось его везде заменить на обычный 403

тоже не идеально, но всё же лучше

Мы на 406 заменили, но думаю тоже не совсем правильно/

здравствуйте, а кто-нибудь щупал openresty в области websocket's?

ПРивет, подскажите, как оформить location, чтоб при обращении <domain_name>/test.tst шло обращение к test.txt файлу?

Модуль ngx_http_index_module
http://nginx.org/ru/docs/http/ngx_http_index_module.html