Случайная ошибка 502/503 на Nginx, работающем за Docker (на кластере ECS + ALB)

Question

Итак, я настроил приложение laravel и разместил его на докере, который, в свою очередь, размещался на кластере AWS ECS, работающем за ALB.

Пока у меня приложение запущено и работает, как и ожидалось, все работает так, как нужноэто так (например, сеансы хранятся в memcached и работают, статические ресурсы находятся в корзине S3 и т. д.).

Сейчас у меня просто 1 проблема со стабильностью, и я не уверен, где именно проблема.Когда я нажимаю на свой URL / веб-сайт, иногда (случайно) он возвращает ошибку 502/503 HTTP.Когда это происходит, мне нужно подождать около минуты или 2, прежде чем приложение сможет вернуть HTTP-код 200.

Вот результат выполнения хвоста на моем докере (т.е. журнал nginx)

На данный момент я полностью потерян и не уверен, где еще я должен проверить.Я попробовал следующее:

1. Запустите его локально, с тем же docker / nginx >> отлично работает.
2. Запустите его без ALB (т.е. используя только 1 EC2)>> с похожей проблемой.
3. Запустите его, используя ALB на 2 разных типах EC2 (т. е. t2.small и micro) >> у обоих схожая проблема.
4. Запустите его с помощью ALB только на 1 EC2>> с похожей проблемой.

Answer 1

Согласно вашим журналам, ngjnx отвечает 401 не авторизованным на запрос проверки работоспособности ALB.Вы должны ответить 200 OK в / конечной точке или настроить другой тип, например /ping в вашей целевой группе ALB.

Чтобы проверить состояние ваших целей с помощью консоли

1. Откройте консоль Amazon EC2 по адресу https://console.aws.amazon.com/ec2/.

2. На панели навигации в разделе НАГРУЗКА НАГРУЗКИ выберите Целевые группы.

3. Выберите целевую группу.

4. На вкладке «Цели» в столбце «Состояние» отображается состояние каждой цели.

5. Если состояние имеет какое-либо значениекроме Healthy, просмотрите подсказку для получения дополнительной информации.

Дополнительная информация: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html

Answer 2

В прошлом у меня была похожая проблема по одной из нескольких возможных причин:

• Проверки работоспособности настроены для ALB, например, ALB ожидает поступления настроенного количества проверокзеленый (например, каждые 30 секунд попадание в конечную точку и ожидание 200 в течение 4/5 раз. Во время «нездоровой фазы» экземпляр можно обозначить как отключенный. Обычно это происходит чаще всего сразу после перезапуска или развертывания или если экземпляр выходит из строя..
• DNS в NGINX. Если DNS-записи нисходящего сервиса, который NGINX осуществляет прокси, изменились, это может быть связано с тем, что NGINX кэшировал (в соответствии с TTL или гораздо дольше в зависимости от вашей конфигурации) старую запись.и поэтому не может подключиться к нисходящему потоку.

Чтобы помочь в полной отладке, возможно, стоит определить, поступает ли 502/503 из ALB или из NGINX. Возможно, вы сможете определить этоиз журнала доступа ALB или /var/log/nginx/access|error.log в контейнере.

Это можетy также помогите проверить, было ли тело ответа на ответ?