Я использую подход, описанный здесь , чтобы переместить сообщения, которые были ошибочно обработаны лямбда-функцией, вызванной SQS, в DeadLetterQueue.
В моем случае ReservedCapacity лямбдыДля функции задано небольшое значение - я хочу ограничить количество одновременных выполнений.Что происходит, даже если журналы / метрики Cloudwatch не отображают ошибки выполнения лямбды, некоторые сообщения не обрабатываются и отправляются в DLQ.
Дросселируется лямбда-функция, что ожидается.Кажется, что когда функция задушена, сообщение удаляется из SQS, а затем возвращается, что приводит к завершению сообщения в DLQ, даже если в коде выполнения лямбда-ошибок нет ошибок.
Сейчас яувеличение maxReceiveCount с 1 до 3 в качестве обходного пути.Есть ли лучший способ отправлять только ошибки выполнения лямбды (не включая регулирование) в DLQ?
SearchJobsQueue:
Type: 'AWS::SQS::Queue'
Properties:
MessageRetentionPeriod: 1209600
VisibilityTimeout: 60
RedrivePolicy:
deadLetterTargetArn:
"Fn::GetAtt":
- SearchJobsDLQ
- Arn
maxReceiveCount: 3
EDIT : Моя цель - чтобы DLQ получал только лямбды с ошибками, которые былине рассматривается явно в лямбда-код.Обходной путь имеет следующие проблемы: в случае постоянных ошибок сообщение будет обработано по крайней мере 3 раза до окончания в DLQ, когда достаточно 1 раза;в зависимости от времени, необходимого для обработки всех сообщений очереди, и от интервала проверки очереди лямбда-триггером, возможно, что сообщение, не обработанное из-за дросселирования 3 раза, заканчивается в DLQ.