Случайно получить 502 неверный ответ шлюза от AWS API Gateway после изменения времени выполнения Lambda с узла 8.x на узел 12.x - PullRequest
Новая
       5

Случайно получить 502 неверный ответ шлюза от AWS API Gateway после изменения времени выполнения Lambda с узла 8.x на узел 12.x

4 голосов
/ 22 января 2020

Поскольку NodeJS 8.x время выполнения на AWS Lambda - это EOL, мы переместили нашу промежуточную среду для нашего REST API в NodeJS 12.x ..

Теперь мы заметили, что в некоторых случаях случайный запрос времени от веб-приложения внешнего интерфейса к шлюзу API завершается с ошибкой 502. Обычно это происходит после некоторого простоя API (несколько минут). В основном это происходит для запросов OPTIONS или HEAD, но это, вероятно, потому, что это первый запрос после некоторого времени простоя. Все последующие запросы к API работают нормально. Даже если вы обновите sh веб-сайт, все запросы go будут выполнены без проблем.

Я не могу найти журналы на Lambda.

Журнал шлюза API: 

"error":  "Internal server error", "ErrorDetail": " "Internal server error"", "errorValidation": "-", "errorResponseType": "INTEGRATION_FAILURE"

Также у нас возникают те же проблемы с rumtime NodeJS 10.x, но не с NodeJs 8.

Спасибо за вашу помощь!

Ответы [ 3 ]

0 голосов
/ 22 января 2020

Звучит также как холодный старт лямбды Холодный запуск в AWS Лямбда

Проверьте, может быть, что-то может увеличить время холодного запуска лямбды.

0 голосов
/ 23 января 2020

Похоже, мы нашли ошибку - она ​​была в коде. :)

Через некоторое время мы обнаружили журналы Lambda в Cloud Watch, которые соответствуют журналам API Gateway, и мы увидели некоторые тайм-ауты базы данных. Мы все еще изучаем детали, но проблема заключалась в express промежуточном программном обеспечении для ведения журнала.

Он обращался к базе данных даже по запросам OPTIONS и HEAD, а также до того, как соединение с базой данных было подтверждено. Проблема может быть связана с тайм-аутом сокета базы данных и продолжительностью жизни лямбды. Тем не менее, простая попытка обхода промежуточного программного обеспечения для журналов, по-видимому, устранила проблему.

Мы все еще не уверены, почему ошибки не возникали на производстве с Node 8. Traffi c, вероятно, был достаточно высок, чтобы поддерживать соединение с базой данных открытым.

Спасибо, ребята, за помощь.

0 голосов
/ 22 января 2020

давайте посмотрим, на основе предоставленной вами информации может быть три вещи:

  1. Лямбда-функция должна возвращать JSON ответ, как описано здесь: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html
  2. другим вариантом будут ограничения IAM.
  3. Или лямбда-выражение отправляет JSON, у которого есть параметр тела, содержащий экранированные данные JSON, например: 
 {
  "statusCode": 200,
  "body": "[\"aaa\",\"ccc\",\"ggg\",\"bbb\",\"ddd\"]"
 }

ОБНОВЛЕНИЕ:

Вы получаете ошибки при операциях OPTION & HEAD, которые являются предварительными вызовами из браузера для проверки CORS.

То, что я сделал, было:

Браузер, выполняющий вызов OPTIONS перед полетом, «INDEED» проходит весь путь до серверной части. Свидетельствуйте следующее: 

{"result":"-err","number":1,"message":"The quantity and/or type of parameters provided is incorrect."}

То, что вы видите, - это ответ, который я получаю на предполетный вызов Chrome OPTIONS. Это мой собственный обработчик ErrorMessage в моем приложении узла, который жалуется, что вы запустили приложение, не предоставив ему надлежащие входные данные. Предварительный вызов OPTIONS не выполняет POST JSON (очевидно), поэтому приложение разозлилось.

Я не думаю, что оно повлияет на ваше приложение в целом, но тогда может произойти решение проблемы со стороны AWS API GATEWAY.

...