Хорошо, вот сценарий. Мы отправляем наши запросы API на сервер NGINX, который затем перенаправляет его на AWS Elastic Load Balancer, цели которого указывают на наши внутренние серверы. Бэкэнд-сервер обрабатывает запрос, возвращает ответ. Ничего необычного, верно?
Ну, по какой-то причине иногда POST-запросы, поступающие от определенного ресурса API, заканчиваются на 403. Мы видим это в журналах Proxy Server (/ var / log /nginx / access.log), что возвращается 403, а затем журналы Load Balancer (журналы доступа, записи в S3) также говорят 403. Однако на внутренних серверах (catalina.out) вообще нет журналов, говорящих о том, что запрос даже поступил, Это заставляет меня поверить, что балансировщик нагрузки каким-то образом отбрасывает некоторые запросы и никогда не обращается к бэкэнду. Конечно, это всего лишь предположение на уровне поверхности. Я действительно не уверен, где запрос застревает / отбрасывается.
Следует отметить, что во время сценария 403 для нашего запроса возвращается только около 60 мсек. Если возвращается 403. 200, обычно это занимает около 250 мс. Таким образом, похоже, что балансировщик нагрузки даже не пытается перенести его на внутренний сервер, а просто где-то принимает 403.
Это прерывистость только усугубляет проблему, так как определение проблемы дажесложнее.
Мы на самом деле пытались перейти на современный Application Load Balancer, и какое-то время проблема как будто уменьшалась. Но теперь мы снова получаем более прерывистые 403, даже с обновленным Балансировщиком нагрузки.
Сейчас проблема почти год назад, и до сих пор не найдено решение, которое бы увеличило вероятность Запрещения 403 почти до 0%. .
Совершенно в замешательстве здесь. Любая идея будет оценена.