Capturar registros de invocações assíncronas do Lambda

O Lambda pode enviar os registros de invocações assíncronas a um dos Serviços da AWS a seguir.

O registro de invocação contém detalhes sobre a solicitação e a resposta no formato JSON. É possível configurar destinos separados para eventos que são processados com êxito e eventos em que há falha no processamento de todas as tentativas. Como alternativa, é possível configurar uma fila padrão do Amazon SQS ou um tópico padrão do Amazon SNS como uma fila de mensagens não entregues para os eventos descartados. Para filas de mensagens mortas, o Lambda envia somente o conteúdo do evento, sem detalhes sobre a resposta.

Se o Lambda não conseguir enviar um registro para um destino que você configurou, ele enviará uma métrica DestinationDeliveryFailures para o Amazon CloudWatch. Isso poderá acontecer se sua configuração incluir um tipo de destino incompatível, como uma fila do Amazon SQS FIFO ou um tópico do Amazon SNS FIFO. Os erros de entrega também podem ocorrer devido a erros de permissão e limites de tamanho. Para obter mais informações sobre as métricas de invocação do Lambda, consulte Métricas de invocação.

Adicionar um destino

Para reter registros de invocações assíncronas, adicione um destino à função. Você pode optar por enviar invocações com êxito ou com falha para um destino. Cada função pode ter vários destinos para que você possa configurar destinos separados para eventos com êxito e com falha. Cada registro enviado ao destino é um documento JSON com detalhes sobre a invocação. Da mesma forma que as configurações de tratamento de erros, é possível configurar destinos em uma função, em uma versão de função ou em um alias.

A tabela a seguir lista os destinos aceitos para registros de invocação assíncrona. Para que o Lambda envie registros com êxito ao destino escolhido, certifique-se de que o perfil de execução da função também contenha as permissões relevantes. A tabela também descreve como cada tipo de destino recebe o registro de invocação JSON.

As etapas a seguir descrevem como configurar um destino para uma função usando o console do Lambda e a AWS CLI.

Práticas recomendadas de segurança para destinos do Amazon S3

Excluir um bucket do S3 configurado como destino sem remover o destino da configuração da sua função pode criar um risco de segurança. Se outro usuário souber o nome do seu bucket de destino, ele poderá recriar o bucket na Conta da AWS dele. Registros de invocações com falha serão enviados para o bucket do usuário, potencialmente expondo dados da sua função.

O exemplo a seguir mostra uma política do IAM que limita as permissões s3:PutObject da função aos bucket da conta. Essa política também dá ao Lambda a permissão s3:ListBucket necessária para usar um bucket do S3 como destino.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3BucketResourceAccountWrite",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::*/*",
            "Condition": {
                "StringEquals": {
                    "s3:ResourceAccount": "111122223333"
                }
            }
        }
    ]
}

Para adicionar uma política de permissões ao perfil de execução da função usando o AWS Management Console ou a AWS CLI, consulte as instruções nos seguintes procedimentos:

Exemplo de registro de invocação

Quando uma invocação corresponde à condição, o Lambda envia um documento JSON com detalhes sobre a invocação para o destino. O exemplo a seguir mostra um registro de invocação para um evento que teve três falhas de tentativa de processamento devido a um erro de função.

{
    "version": "1.0",
    "timestamp": "2019-11-14T18:16:05.568Z",
    "requestContext": {
        "requestId": "e4b46cbf-b738-xmpl-8880-a18cdf61200e",
        "functionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST",
        "condition": "RetriesExhausted",
        "approximateInvokeCount": 3
    },
    "requestPayload": {
        "ORDER_IDS": [
            "9e07af03-ce31-4ff3-xmpl-36dce652cb4f",
            "637de236-e7b2-464e-xmpl-baf57f86bb53",
            "a81ddca6-2c35-45c7-xmpl-c3a03a31ed15"
        ]
    },
    "responseContext": {
        "statusCode": 200,
        "executedVersion": "$LATEST",
        "functionError": "Unhandled"
    },
    "responsePayload": {
        "errorMessage": "RequestId: e4b46cbf-b738-xmpl-8880-a18cdf61200e Process exited before completing request"
    }
}

O registro de invocação contém detalhes sobre o evento, a resposta e o motivo pelo qual o registro foi enviado.

Rastreamento de solicitações até destinos

Você pode usar o AWS X-Ray para exibir uma visualização conectada de cada solicitação à medida que ela é adicionada à fila, processada por uma função do Lambda e passada para o serviço de destino. Quando você ativa o rastreamento com X-Ray para uma função ou um serviço que invoca uma função, o Lambda adiciona um cabeçalho X-Ray à solicitação e passa o cabeçalho para o serviço de destino. Os rastreamentos dos serviços de upstream são vinculados automaticamente aos rastreamentos de funções do Lambda e serviços de downstream, o que cria uma visão completa de toda a aplicação. Para obter mais informações sobre rastreamento, consulte Visualizar as invocações da função do Lambda usando o AWS X-Ray.

Adicionar uma fila de mensagens não entregues

Como alternativa a um destino em caso de falha, é possível configurar a função com uma fila de mensagens mortas para salvar eventos descartados para processamento adicional. Uma fila de mensagens mortas age da mesma forma que um destino em caso de falha na medida em que é usado quando há falha em todas as tentativas de processamento de um evento ou ele expira sem ser processado. Porém, você só pode adicionar ou remover uma fila de mensagens não entregues no nível da função. As versões da função usam as mesmas configurações de fila de mensagens não entregues ($LATEST). Destinos em caso de falha também oferecem suporte a destinos adicionais e incluem detalhes sobre a resposta da função no registro de invocação.

Para reprocessar eventos em uma fila de mensagens não entregues, você poderá defini-la como uma origem de eventos para a função do Lambda. Você também pode recuperar os eventos manualmente.

É possível escolher uma fila padrão do Amazon SQS ou um tópico padrão do Amazon SNS para a sua fila de mensagens não entregues. As filas FIFO e os tópicos do Amazon SNS FIFO são incompatíveis.

Sua função precisa de permissões adicionais para enviar eventos a uma fila ou um tópico. Adicione uma política com as permissões necessárias ao perfil de execução da sua função. Se a fila ou o tópico de destino for criptografado com uma chave do AWS KMS gerenciada pelo cliente, certifique-se de que tanto a função de execução da sua função quanto a política baseada em recursos da chave contenham as permissões relevantes.

Depois de criar o destino e atualizar a função de execução de sua função, adicione a fila de mensagens mortas à função. Você pode configurar várias funções para enviarem eventos ao mesmo destino.

O Lambda envia o evento para a fila de mensagens mortas no mesmo estado, mais informações adicionais nos atributos. Você pode usar essas informações para identificar o erro retornado pela função, ou correlacionar o evento com logs ou um rastreamento do AWS X-Ray.

Se o Lambda não puder enviar uma mensagem para a fila de mensagens mortas, ele excluirá o evento e emitirá a métrica DeadLetterErrors. Isso pode acontecer por causa de falta de permissões, ou se o tamanho total da mensagem exceder o limite da fila ou do tópico de destino. Por exemplo, digamos que uma notificação do Amazon SNS com um tamanho de quase 256 KB acione uma função que resulte em erro. Nesse caso, os dados do evento incluídos pelo Amazon SNS, combinados aos atributos adicionados pelo Lambda, podem fazer com que a mensagem exceda o tamanho máximo permitido na fila de mensagens não entregues.

Se você está usando o Amazon SQS como uma fonte de eventos, configure uma fila de mensagens mortas na própria fila do Amazon SQS e não na função do Lambda. Para ter mais informações, consulte Usar o Lambda com o Amazon SQS.