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