Para lidar com erros relacionados a uma fonte de eventos do SQS, o Lambda usa automaticamente uma estratégia de repetição com uma estratégia de recuo. Você também pode personalizar o comportamento de tratamento de erros configurando o mapeamento de origem de eventos do SQS para retornar respostas parciais em lote.
Estratégia de recuo para invocações com falha
Quando uma invocação falha, o Lambda tenta repetir a invocação enquanto implementa uma estratégia de recuo. A estratégia de recuo difere ligeiramente caso o Lambda tenha encontrado a falha devido a um erro no código da função ou devido ao controle de utilização.
-
Se o código da função causou o erro, o Lambda interromperá o processamento e repetirá a invocação. Enquanto isso, o Lambda recua gradualmente, reduzindo a quantidade de simultaneidade alocada ao mapeamento da origem do evento do Amazon SQS. Depois que limite de tempo de visibilidade da sua fila se esgotar, a mensagem será mostrada novamente na fila.
-
Se a invocação apresentar falhas devido ao controle de utilização, o Lambda recua gradualmente as novas tentativas, reduzindo a quantidade de simultaneidade alocada para o mapeamento da origem do evento do Amazon SQS. O Lambda continuará a repetir a mensagem até que o carimbo de data/hora da mensagem exceda o tempo limite de visibilidade da fila, que corresponde ao momento em que o Lambda descartará a mensagem.
Implementar respostas parciais em lote
Quando sua função do Lambda encontra um erro ao processar um lote, todas as mensagens nesse lote tornam-se novamente visíveis na fila por padrão, incluindo mensagens que o Lambda processou com sucesso. Como resultado, a função pode acabar processando a mesma mensagem diversas vezes.
Para não precisar reprocessar todas as mensagens processadas com êxito em um lote com falha, você pode configurar o mapeamento da origem do evento para tornar visíveis novamente apenas as mensagens com falha. Isso se chama resposta parcial em lote. Para ativar respostas parciais em lote, especifique ReportBatchItemFailures
para a ação FunctionResponseTypes ao configurar o mapeamento da origem do evento. Isso permite que a função retorne um sucesso parcial, podendo ajudar a reduzir o número de novas tentativas desnecessárias nos registros.
Quando ReportBatchItemFailures
estiver ativado, o Lambda não reduzirá a escala verticalmente da sondagem de mensagens quando as invocações de funções falharem. Se você espera que algumas mensagens falhem, e não quer que essas falhas afetem a taxa de processamento de mensagens, use ReportBatchItemFailures
.
nota
Ao usar respostas parciais em lote, tenha em mente:
-
Se a sua função lançar uma exceção, o lote inteiro será considerado uma falha total.
-
Se você estiver usando esse recurso com uma fila FIFO, a função deverá interromper o processamento de mensagens após a primeira falha e retornar todas as mensagens com falha e não processadas no
batchItemFailures
. Isso ajuda a preservar a ordem das mensagens na sua fila.
Para ativar o relatório parcial em lote
-
Leia as práticas recomendadas para implementar respostas parciais em lote.
-
Execute o comando a seguir para ativar
ReportBatchItemFailures
para a função. Para recuperar o UUID do mapeamento da origem do evento, execute o comando list-event-source-mappings da AWS CLI.aws lambda update-event-source-mapping \ --uuid
"a1b2c3d4-5678-90ab-cdef-11111EXAMPLE"
\ --function-response-types"ReportBatchItemFailures"
-
Atualize o código da função para capturar todas as exceções e retornar mensagens com falha em uma resposta
batchItemFailures
do JSON. A respostabatchItemFailures
deve incluir uma lista de IDs de mensagens, como valoresitemIdentifier
do JSON.Por exemplo, suponha que você tenha um lote de cinco mensagens, com os IDs de mensagem
id1
,id2
,id3
,id4
eid5
. Sua função processaid1
,id3
eid5
com sucesso. Para tornar as mensagensid2
eid4
novamente visíveis na fila, a função deve retornar a seguinte resposta:{ "batchItemFailures": [ { "itemIdentifier": "id2" }, { "itemIdentifier": "id4" } ] }
Veja alguns exemplos de código de função que retornam a lista de IDs de mensagens com falha no lote:
- AWS SDK for .NET
-
nota
Há mais no GitHub. Encontre o exemplo completo e saiba como configurar e executar no repositório dos Exemplos sem servidor
. Relatar falhas de itens em lote do SQS com o Lambda usando o .NET.
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: Apache-2.0 using Amazon.Lambda.Core; using Amazon.Lambda.SQSEvents; // Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class. [assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))] namespace sqsSample; public class Function { public async Task<SQSBatchResponse> FunctionHandler(SQSEvent evnt, ILambdaContext context) { List<SQSBatchResponse.BatchItemFailure> batchItemFailures = new List<SQSBatchResponse.BatchItemFailure>(); foreach(var message in evnt.Records) { try { //process your message await ProcessMessageAsync(message, context); } catch (System.Exception) { //Add failed message identifier to the batchItemFailures list batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId}); } } return new SQSBatchResponse(batchItemFailures); } private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context) { if (String.IsNullOrEmpty(message.Body)) { throw new Exception("No Body in SQS Message."); } context.Logger.LogInformation($"Processed message {message.Body}"); // TODO: Do interesting work based on the new message await Task.CompletedTask; } }
Se os eventos com falha não retornarem à fila, consulte Como soluciono problemas da função do Lambda do SQS ReportBatchItemFailures?
Condições de sucesso e falha
O Lambda considera um lote um sucesso total quando a função retorna qualquer um dos seguintes:
-
Uma lista de
batchItemFailures
vazia -
Uma lista de
batchItemFailures
nula -
Uma
EventResponse
vazia -
Uma
EventResponse
nula
O Lambda considera um lote uma falha total quando a função retorna qualquer um dos seguintes:
-
Uma resposta JSON inválida
-
Uma string
itemIdentifier
vazia -
Uma
itemIdentifier
nula -
Um
itemIdentifier
com um nome de chave inválido -
Um valor
itemIdentifier
com um ID de mensagem inexistente
Métricas do CloudWatch
Para determinar se a função está reportando falhas de itens em lote corretamente, é possível monitorar as métricas do Amazon SQS NumberOfMessagesDeleted
e ApproximateAgeOfOldestMessage
no Amazon CloudWatch.
-
NumberOfMessagesDeleted
rastreia o número de mensagens removidas da sua fila. Se o número cair para 0, é um sinal de que a resposta da função não está retornando corretamente mensagens com falha. -
ApproximateAgeOfOldestMessage
rastreia quanto tempo a mensagem mais antiga permaneceu na sua fila. Um aumento acentuado nessa métrica pode indicar que a função não está retornando mensagens com falha corretamente.