Какой код состояния HTTP, чтобы экземпляры не были помечены как неисправные на AWS Elastic Beanstalk
Я запускаю приложение на AWS Elastic Beanstalk. Если экземпляр отвечает слишком часто кодом состояния HTTP в диапазоне 500 (ошибка сервера), AWS помечает этот экземпляр как неисправный и удаляет экземпляр из балансировщика нагрузки.
Я понимаю это и согласен, что это действительно хорошее поведение. Но, к сожалению, это приводит к проблемам с моим приложением.
Моему приложению необходимо подключиться к нескольким внешним API и агрегировать их данные. Один из внешних API-интерфейсов, который не находится под моим контролем, является нестабильным и довольно часто отвечает кодом состояния 500.
В настоящий момент, если API вызывает ошибку, мое приложение просто передает эту ошибку обратно пользователю. Причина, по которой AWS думает , в моем приложении произошла ошибка, поэтому этот экземпляр был прерван, а новый сервер запущен. Но на самом деле это только одна конечная точка, вызывающая постоянную скорость 500 ошибок, тогда как все остальные конечные точки все еще в порядке.
С одной стороны, это правильно, что ошибка внешнего сервера заставляет мое приложение просто возвращать эту ошибку . С другой стороны, такой ошибки внешнего сервера нет в моем приложении, и я мог бы ее поймать. Но даже если я поймаю ошибку, я не смогу вернуть что-либо полезное пользователю, и поэтому мне все равно нужно вернуться с кодом ошибки.
Как с этим справиться? Избегать кодов состояния ошибки сервера, чтобы не запускать нездоровые экземпляры, но в то же время не использовать код состояния ошибки клиента, потому что пользователь ничего не может сделать, ему просто нужно повторить попытку?
Что вы предлагаете? Или есть другой вариант для тонкой настройки поведения AWS Elastic Beanstalks?
Главный вопрос заключается в следующем: когда запросы к этому API терпят неудачу, требует ли рабочий процесс вашего приложения, чтобы ваши клиенты / пользователи
а) быть уведомленным об этом
б) необходимо предпринять последующие действия
c) является ли ответ об ошибке HTTP единственным способом уведомить об этом?
Если да, то подумайте, когда удаленный API генерирует внутреннюю ошибку сервера 500, чтобы ваше приложение возвращало ответ об ошибке 408, что в некоторой степени подходит, поскольку позволяет клиенту повторно отправить тот же запрос в более поздний момент. («502 Bad Gateway» был бы лучше, если бы не ограничение ниже :)
Кроме того, вы можете настроить расширенные правила работоспособности в Elastic Beanstalk, где вы указываете эластичному beanstalk игнорировать ошибки 4xx как показательные плохое здоровье. К сожалению, на момент написания вы не могли сделать то же самое для 5xx или даже более конкретных кодов статуса http.