Comments 4
Спасибо за примеры конфигов.
Однако, стоит отметить, что одна из частых причин ошибок 5xx — это невыложенное обновление на одну из реплик серверов.
Причин может быть масса:
У нас на репликах серверов настроено независимое логирование 5xx ошибок. Да, оно менее информативное, и его можно комбинировать с вашим способом, но забывать про это не стоит.
Однако, стоит отметить, что одна из частых причин ошибок 5xx — это невыложенное обновление на одну из реплик серверов.
Причин может быть масса:
- выкладывали вручную, забыли что-то сделать
- выкладывал CI (напр., TeamCity), что-то сбойнуло (сервер ставил обновления ОС и ребутался; сервер чуть отличается в настройках, что повлияло на обновление; антивирусное ПО ложно сработало эвристикой; к этой реплике сервера шел запрос от пользователя — файл был занят — не удалось заменить; и так далее, список можно долго продолжать)
У нас на репликах серверов настроено независимое логирование 5xx ошибок. Да, оно менее информативное, и его можно комбинировать с вашим способом, но забывать про это не стоит.
Обновление ОС и ребут на продакшене? Звучит как «автоматическое» :) Но есть хорошая практика нотификаций и согласований с ответственными за систему и девопс отделом как минимум.
Еще хорошая практика проверить что прилетело на сервер физически. Есть serverspec например. К тому же вывести репику из апстрима тоже хорошая идея и вернуть только после теста.
Ну эт так, что первое в голову пришло. В общем — «что-то сбойнуло» — неправильно построенный деплой процесс как минимум.
Еще хорошая практика проверить что прилетело на сервер физически. Есть serverspec например. К тому же вывести репику из апстрима тоже хорошая идея и вернуть только после теста.
Ну эт так, что первое в голову пришло. В общем — «что-то сбойнуло» — неправильно построенный деплой процесс как минимум.
В приведенных примерах юзеру придется ждать последовательной обработки его запроса двумя бекендами, прежде чем он получит болт. Это не очень хорошо. Обратите внимание на недокументированную (но давно работающую) директиву post_action. С ее помощью можно уже после обработки запроса для клиента перейти в именованный локейшн. Так, в вашем случае можно быстренько отдать клиенту какой-нибудь там /error/500.html, и уже неспешно сделать post_action на дебажный сервер. Юзер его результатов не увидит и ждать лишнее время не будет.
Sign up to leave a comment.
NGINX: Перехват ошибок 5хх с помощью отладочного сервера