Lidar com erros e novas tentativas automáticas no AWS Lambda - AWS Lambda

Lidar com erros e novas tentativas automáticas no AWS Lambda

Dois tipos de erro podem ocorrer quando você invoca uma função. Os erros de invocação ocorrem quando a solicitação de invocação for rejeitada antes da função recebê-la. Erros de função ocorrem quando o código ou o tempo de execução de sua função retornarem um erro. O comportamento de novas tentativas e a estratégia de gerenciamento de erros varia de acordo com o tipo de erro, o tipo de chamada e o cliente ou serviço que chama a função.

Problemas com a solicitação, o chamador e a conta podem causar erros de invocação. Os erros de invocação incluem um tipo de erro e um código de status na resposta que indicam a causa do erro.

Erros de invocação comuns

  • Request (Solicitação) – o evento de solicitação é muito grande ou não é um JSON válido, a função não existe ou um valor de parâmetro é do tipo errado.

  • Caller (Chamador) – o usuário ou o serviço não tem permissão para chamar a função.

  • Account (Conta) – o número máximo de instâncias de função já está em execução, ou as solicitações estão sendo feitas muito rápido.

Clientes como a AWS CLI e a SDK da AWS fazem novas tentativas em tempo limite atingido, erros de limitação (429) e outros erros não causados por solicitações inválidas (série 500). Para obter uma lista completa de erros de invocação, consulte Invoke.

Erros de função ocorrem quando seu código de função ou o tempo de execução que ele usa retornarem um erro.

Erros de função comuns

  • Function (Função) – o código de sua função abre uma exceção ou retorna um erro.

  • Runtime (Tempo de execução) – o tempo de execução encerrou sua função porque detectou um erro de sintaxe, falhou em ordenar o objeto de resposta no JSON ou o limite de tempo foi atingido. A função foi encerrada com um código de erro.

Ao contrário dos erros de chamada, erros de função não fazem o Lambda retornar erros de status das séries 400 ou 500. Se a função retorna um erro, o Lambda indica isso ao incluir um cabeçalho chamado X-Amz-Function-Error e uma resposta em JSON com a mensagem de erro e outros detalhes. Para ver exemplos de erros de função em cada linguagem, consulte os tópicos a seguir.

Ao invocar um função diretamente, você determinará a estratégia para lidar com erros. Você pode tentar novamente, enviar o evento para uma fila de depuração ou ignorá-lo. O código de sua função pode ter sido executado completa ou parcialmente, ou nem ter sido executado. Se você tentar novamente, certifique-se de que o código de sua função pode lidar com o mesmo evento várias vezes sem duplicar transações nem ter efeitos colaterais indesejados.

Ao invocar um função indiretamente, você deve estar ciente do comportamento de novas tentativas do invocador e dos serviços que podem interagir com a solicitação no processo. Isso inclui as seguintes situações.

  • Asynchronous Invocation (Chamada assíncrona) – o Lambda faz duas novas tentativas de erros de função. Se a função não tiver capacidade suficiente para lidar com todas as solicitações em andamento, os eventos poderão ter de aguardar na fila por horas ou dias até serem enviados para a função. Você pode configurar uma fila de mensagens mortas na função para registrar eventos que não foram processadas com êxito. Para obter mais informações, consulte Invocação assíncrona.

  • Event source mappings (Mapeamento da fonte do evento) – mapeamentos da fonte do evento que leem das transmissões repetem todo o lote de itens. Os erros repetidos bloqueiam o processamento do estilhaço afetado até o erro ser resolvido ou os itens expirarem. Para detectar estilhaços interrompidos, é possível monitorar a métrica Iterator Age (Idade do iterador).

    Para mapeamentos da fonte do evento que leem de uma fila, você mesmo determina o intervalo de tempo entre repetições e o destino de eventos falhos. Para fazer isso, configure o tempo limite de visibilidade e a política de redirecionamento na fila de origem. Para obter mais informações, consulte Mapeamentos da fonte de eventos do AWS Lambda e os tópicos específicos do serviço em Usar o AWS Lambda com outros serviços.

  • AWS services (Produtos da AWS) – os produtos da AWS podem chamar uma função de maneira síncrona ou assíncrona. Para chamada síncrona, o serviço decide se deve tentar novamente. Serviços como API Gateway e Elastic Load Balancing, que fazem o proxy de solicitações de um usuário ou cliente upstream, também podem optar por retransmitir a resposta de erro de volta ao solicitante.

    Para invocação assíncrona, o comportamento é o mesmo de quando você invoca a função de maneira assíncrona. Para obter mais informações, consulte os tópicos específicos do serviço em Usar o AWS Lambda com outros serviços e a documentação do serviço de invocação.

  • Other Accounts and Clients (Outras contas e clientes) – ao conceder acesso a outras contas, você pode usar as políticas baseadas em recursos para restringir os serviços ou recursos que eles podem configurar para chamar sua função. Para evitar que a função fique sobrecarregada, considere colocar uma camada de API na frente da função com o Amazon API Gateway.

Para ajudar você a lidar com erros em aplicativos do Lambda, o Lambda se integra com serviços como o Amazon CloudWatch e o AWS X-Ray. Você pode usar um conjunto de logs, métricas, alarmes e rastreamento para detectar e identificar rapidamente os problemas no código da função, na API ou em outros recursos compatíveis com seu aplicativo. Para obter mais informações, consulte Monitoramento e solução de problemas de aplicativos do Lambda.

Para ver um aplicativo de exemplo que usa uma assinatura do CloudWatch Logs, rastreamento do X-Ray e uma função do Lambda para detectar e processar erros, consulte Aplicativo de exemplo de processador de erros para o AWS Lambda.