Captura de los registros de invocaciones asíncronas de Lambda

Lambda puede enviar registros de invocaciones asíncronas a uno de los siguientes Servicios de AWS.

El registro de invocación contiene detalles sobre la solicitud y la respuesta en formato JSON. Puede configurar destinos independientes en eventos que se procesan con éxito, y eventos que fallan todos los intentos de procesamiento. También puede configurar una cola de Amazon SQS estándar o un tema de Amazon SNS estándar como una cola de mensajes fallidos para eventos descartados. En las colas de mensajes fallidos, Lambda solo envía el contenido del evento, sin detalles sobre la respuesta.

Si Lambda no puede enviar un registro a un destino que haya configurado, envía una métrica DestinationDeliveryFailures a Amazon CloudWatch. Esto puede ocurrir si la configuración incluye un tipo de destino no admitido, como una cola FIFO de Amazon SQS o un tema FIFO de Amazon SNS. También pueden producirse errores de entrega debido a errores de permisos y límites de tamaño. Para obtener más información sobre las métricas de invocación de Lambda, consulte Métricas de invocación.

Cómo agregar un destino

Para retener registros de invocaciones asincrónicas, agregue un destino a su función. Puede elegir enviar las invocaciones correctas o fallidas a un destino. Cada función puede tener varios destinos, por lo que puede configurar destinos independientes para los eventos correctos y los fallidos. Cada registro enviado al destino es un documento JSON con detalles sobre la invocación. Al igual que con los ajustes de gestión de errores, puede configurar los destinos en una función, versión de la función o alias.

La siguiente table enumera los destinos admitidos para los registros de invocación asincrónica. Para que Lambda envíe correctamente los registros al destino elegido, asegúrese de que el rol de ejecución de la función también contenga los permisos pertinentes. En la tabla también se describe cómo cada tipo de destino recibe el registro de invocación de JSON.

En los siguientes pasos se describe cómo configurar un destino para una función utilizando la consola de Lambda y la AWS CLI.

Prácticas recomendadas de seguridad para destinos de Amazon S3

Eliminar un bucket de S3 que está configurado como destino sin eliminar el destino de la configuración de la función puede suponer un riesgo de seguridad. Si otro usuario conoce el nombre del bucket de destino, puede volver a crear el bucket en su Cuenta de AWS. Los registros de las invocaciones fallidas se enviarán a su bucket, lo que podría exponer los datos de su función.

En el siguiente ejemplo, se muestra una política de IAM que limita los permisos s3:PutObject de la función a los buckets de la cuenta. Esta política también otorga a Lambda el permiso s3:ListBucket que necesita para usar un bucket de S3 como destino.

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

Para agregar una política de permisos al rol de ejecución de su función mediante la AWS Management Console o AWS CLI, consulte las instrucciones de los siguientes procedimientos:

Registro de invocación de ejemplo

Cuando una invocación coincide con la condición, Lambda envía un documento JSON con detalles sobre la invocación al destino. El ejemplo siguiente muestra un registro de invocación para un evento que ha fallado tres intentos de procesamiento debido a un error de función.

{
    "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"
    }
}

El registro de invocación contiene detalles sobre el evento, la respuesta y el motivo por el que se ha enviado el registro.

Seguimiento de solicitudes a destinos

Puede utilizar AWS X-Ray para ver una vista conectada de cada solicitud a medida que se pone en cola, la procesa una función de Lambda y se pasa al servicio de destino. Al activar el seguimiento de X-Ray para una función o un servicio que invoca una función, Lambda agrega un encabezado de X-Ray a la solicitud y lo pasa al servicio de destino. El seguimiento de los servicios anteriores se vincula automáticamente al seguimiento de las funciones de Lambda posteriores, lo que crea una vista integral de toda la aplicación. Para obtener más información sobre el seguimiento, consulte Visualice las invocaciones de la función de Lambda mediante AWS X-Ray.

Cómo agregar una cola de mensajes fallidos

Como alternativa a un destino en caso de fallo, puede configurar su función con una cola de mensajes fallidos para guardar eventos descartados para su posterior procesamiento. Una cola de mensajes fallidos actúa igual que un destino en caso de error, ya que se utiliza cuando un evento falla todos los intentos de procesamiento o caduca sin ser procesado. Sin embargo, solo puede agregar o eliminar una cola de mensajes fallidos a nivel de función. Las versiones de la función usan la misma configuración de cola de mensajes fallidos que la versión no publicada ($LATEST). Los destinos en caso de error también admiten destinos adicionales e incluyen detalles sobre la respuesta de la función en el registro de invocación.

Para volver a procesar los eventos en una cola de mensajes fallidos, puede configurarla como un origen de eventos para su función de Lambda. También puede recuperar manualmente los eventos.

Puede elegir una cola de Amazon SQS estándar o un tema estándar de Amazon SNS para la cola de mensajes fallidos. No se admiten las colas FIFO ni los temas FIFO de Amazon SNS.

Para enviar eventos a una cola o tema, la función necesita permisos adicionales. Agregue una política con los permisos necesarios al rol de ejecución de la función. Si la cola o el tema de destino están cifrados con una clave de AWS KMS administrada por el cliente, asegúrese de que tanto el rol de ejecución de su función como la política basada en recursos de la clave cuentan con los permisos pertinentes.

Después de crear el destino y actualizar el rol de ejecución de la función, añada la cola de mensajes fallidos a la función. Puede configurar varias funciones para enviar eventos al mismo destino.

Lambda envía el evento a la cola de mensajes fallidos tal y como está, con información adicional en atributos. Puede utilizar esta información para identificar el error que la función devuelve o correlacionar el evento con los registros o un rastro de AWS X-Ray.

Si Lambda no puede enviar un mensaje a la cola de mensajes fallidos, elimina el evento y emite la métrica DeadLetterErrors. Esto puede ocurrir debido a la falta de permisos o si el tamaño total del mensaje supera el límite de la cola o tema de destino. Por ejemplo, supongamos que una notificación de Amazon SNS con un cuerpo cercano a los 256 KB activa una función que genera un error. En ese caso, los datos del evento que Amazon SNS agrega, junto con los atributos agregados por Lambda, pueden hacer que el mensaje supere el tamaño máximo permitido en la cola de mensajes fallidos.

Si está utilizando Amazon SQS como fuente de eventos, configure una cola de mensajes fallidos en la propia cola de Amazon SQS y no en la función de Lambda. Para obtener más información, consulte Uso de Lambda con Amazon SQS.