AWS Lambda python Сброс сброшенного соединения

Question

У меня есть AWS Python Lambda, который управляет тегами ресурсов (многие вызовы API AWS с boto3) для моей инфраструктуры. Функция, выполняемая на моем ноутбуке, хорошо работает, а также под Lambda. Но когда я выполняю его под Lambda, все мои журналы (уровень отладки или ошибки) не отправляются в журналы cloudwatch. Вместо того, чтобы Я несколько журналов, как это:

Resetting dropped connection: ec2.us-west-2.amazonaws.com 
Resetting dropped connection: ec2.us-west-2.amazonaws.com 

Google сказал мне, что это проблема относительно urlib3 и слишком высокая частота запроса по отношению к API AWS.

Вопрос в том, как избежать этого в Лямбде, чтобы получить мои журналы в журналах cloudwatch? Я ищу лучшее решение, чем многократный сон внутри моего кода. Есть ли способ сделать это во всем мире?

Благодаря

Answer 1

Хорошо, наконец, это работает. Действительно, я слишком агрессивен в процессе повторных попыток, но мне нужно выполнить каждую операцию как можно скорее (например: прикрепить EBS, когда она доступна). В boto3 есть более чистый способ подождать, пока ресурс станет готовым, чем положить time.sleep (xx) в ваш код.

Решение заключается в использовании boto3 waiter . Мой совет - установить настраиваемое значение для интервала повтора, поскольку по умолчанию оно равно 15 с (слишком длинное).

waiter.config.delay = 1 
waiter.config.max_attempts = 10(as you want for this param) 

С этим параметрам можно избежать лямбда отправлять журналы, как это «Сброс разрыва связи: ec2.us-west-2.amazonaws.com» и вы выполняете свой Lambda самым быстрым способом.

Я согласен с smdev, который сказал, что не стоит спать внутри лямбда-функции (boto3 waiter - это сон, как), но для меня это приемлемо, когда ваша функция лямбда называется только несколько раз. Например, когда уведомление Autoscaling вызывает вашу Лямбду. Если ваша Лямбда вызывается непосредственно по API Gateway (пример) на умеренной или высокой частоте, это очень плохая идея, но если это всего 2-3 раза в день, все в порядке.

Answer 2

AWS журналы clodwatch не будет "перезаписать" свои собственные журналы. Пожалуйста, не спать в лямбда-функции, так как вы будете платить за это. Также, если скорость запроса слишком высока, вы получите ошибки RequestLimitExceeded.

Есть несколько способов, чтобы избежать этого:

1. Проверить и удалить любой Boto код, который звонит по API AWS в сплошном цикле (для/времени)
2. Используйте итераторов, MaxResults и нумерация страниц в Бото код, чтобы получить список/коллекцию элементов вместо запросов для отдельных.
3. Используйте две лямбды с sqs между ними (для случаев, когда есть асинхронная зависимость). Например, если удалять неиспользуемые AMI - один лямбда, чтобы идентифицировать и отменять регистрацию AMI и нажимать связанные снимки на sqs. Вторая лямбда для чтения из sqs и удаления снимков.

Надеюсь, это прояснится.

Answer 3

где поставить эту конфигурацию ожидания:

waiter.config.delay = 1 
waiter.config.max_attempts = 10 

(как вы хотите для этого пар)