Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Capture des enregistrements d’invocations asynchrones Lambda
Lambda peut envoyer des enregistrements d'appels asynchrones à l'une des entités suivantes. Services AWS
-
Amazon SQS : une file d’attente SQS standard
-
Amazon SNS : une rubrique SNS standard
-
Amazon S3 : un compartiment Amazon S3 (uniquement en cas d’échec)
-
AWS Lambda : une fonction Lambda
-
Amazon EventBridge — Un bus EventBridge événementiel
L’enregistrement d’invocation contient des détails sur la demande et la réponse au format JSON. Vous pouvez configurer des destinations distinctes pour les événements qui ont été traités avec succès et ceux dont le traitement a échoué. Vous pouvez également configurer une file d’attente Amazon SQS ou une rubrique Amazon SNS standard en tant que file d’attente de lettres mortes pour les événements abandonnés. Pour les files d’attente de lettres mortes, Lambda envoie uniquement le contenu de l’événement, sans plus d’informations sur la réponse.
Si Lambda ne parvient pas à envoyer un enregistrement vers une destination que vous avez configurée, il envoie une DestinationDeliveryFailures métrique à Amazon. CloudWatch Cela peut se produire si votre configuration inclut un type de destination non pris en charge, tel qu’une file d’attente FIFO Amazon SQS ou une rubrique FIFO Amazon SNS. Des erreurs de remise peuvent également se produire en raison d’erreurs d’autorisations et de limites de taille. Pour plus d’informations sur les métriques d’invocation Lambda, consultez Métriques d'invocation.
Note
Pour empêcher une fonction de se déclencher, vous pouvez définir la simultanéité réservée de la fonction sur zéro. Lorsque vous définissez la simultanéité réservée sur zéro pour une fonction invoquée de manière asynchrone, Lambda commence à envoyer les nouveaux événements à la file d’attente de lettres mortes ou à la destination d’événement en situation d’échec, sans aucune nouvelle tentative. Pour traiter les événements qui ont été envoyés alors que la simultanéité réservée était définie sur zéro, vous devez consommer les événements de la file d’attente de lettres mortes ou de la destination des événements en situation d’échec.
Ajout d’une destination
Pour retenir les enregistrements des invocations asynchrones, ajoutez une destination à votre fonction. Vous pouvez choisir d’envoyer les invocations réussies ou non à une destination. Chaque fonction peut avoir plusieurs destinations. Vous pouvez donc configurer des destinations distinctes pour les événements réussis et échoués. Chaque enregistrement envoyé à la destination est un document JSON avec des détails sur l’invocation. Comme les paramètres de gestion des erreurs, vous pouvez configurer des destinations au niveau d’une fonction, d’une version de fonction ou d’un alias.
Astuce
Vous pouvez également conserver les enregistrements des invocations ayant échoué pour les types de mappage des sources d’événements suivants : Amazon Kinesis, Amazon DynamoDB, Apache Kafka autogéré et Amazon MSK.
Le tableau suivant répertorie les destinations prises en charge pour les enregistrements d’invocation asynchrones. Pour que Lambda envoie correctement les enregistrements vers la destination que vous avez choisie, assurez-vous que le rôle d’exécution de votre fonction contient également les autorisations appropriées. Le tableau décrit également comment chaque type de destination reçoit l’enregistrement d’invocation JSON.
| Type de destination | Autorisation obligatoire | Format JSON spécifique à la destination |
|---|---|---|
|
File d’attente Amazon SQS |
Lambda transmet l’enregistrement d’invocation en tant que |
|
|
Rubrique Amazon SNS |
Lambda transmet l’enregistrement d’invocation en tant que |
|
|
Compartiment Amazon S3 (uniquement en cas d’échec) |
|
|
|
fonction Lambda |
Lambda transmet l’enregistrement d’invocation comme charge utile à la fonction. |
|
|
EventBridge |
|
Note
Pour les destinations Amazon S3, si vous avez activé le chiffrement sur le compartiment à l'aide d'une clé KMS, votre fonction a également besoin de l'GenerateDataKeyautorisation kms :.
Les étapes suivantes expliquent comment configurer une destination pour une fonction à l’aide de la console Lambda et de l’ AWS CLI.
Pratiques exemplaires en matière de sécurité pour les destinations Amazon S3
La suppression d’un compartiment S3 configuré comme destination sans supprimer la destination de la configuration de votre fonction peut engendrer un risque de sécurité. Si un autre utilisateur connaît le nom de votre compartiment de destination, il peut recréer le compartiment dans son Compte AWS. Les enregistrements des invocations ayant échoué seront envoyés dans son compartiment, exposant potentiellement les données de votre fonction.
Avertissement
Pour vous assurer que les enregistrements d'invocation de votre fonction ne peuvent pas être envoyés vers un compartiment S3 d'un autre Compte AWS, ajoutez une condition au rôle d'exécution de votre fonction qui limite s3:PutObject les autorisations aux compartiments de votre compte.
L’exemple suivant présente une politique IAM qui limite les autorisations s3:PutObject de votre fonction aux seuls compartiments de votre compte. Cette politique donne également à Lambda l’autorisation s3:ListBucket dont il a besoin pour utiliser un compartiment S3 comme destination.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "S3BucketResourceAccountWrite", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::*/*", "Condition": { "StringEquals": { "s3:ResourceAccount":"111122223333"} } } ] }
Pour ajouter une politique d'autorisations au rôle d'exécution de votre fonction à l'aide du AWS Management Console or AWS CLI, reportez-vous aux instructions des procédures suivantes :
Exemple d’enregistrement d’invocation
Quand une invocation correspond à la condition, Lambda envoie à la destination un document JSON avec des détails sur l’invocation. L'exemple suivant illustre un enregistrement d'appel pour un événement dont le traitement a échoué à trois reprises en raison d'une erreur de fonction.
{
"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"
}
}L’enregistrement d’invocation contient des détails sur l’événement, la réponse et la raison pour laquelle l’enregistrement a été envoyé.
Suivi des demandes vers les destinations
Vous pouvez utiliser AWS X-Ray pour visualiser une vue connectée de chaque demande lorsqu’elle est placée en file d’attente, traitée par une fonction Lambda et transmise au service de destination. Lorsque vous activez le suivi X-Ray pour une fonction ou un service qui invoque une fonction, Lambda ajoute un en-tête X-Ray à la demande et transmet l’en-tête au service de destination. Les traces des services en amont sont automatiquement liées aux traces des fonctions Lambda en aval et des services de destination, créant ainsi une end-to-end vue de l'ensemble de l'application. Pour plus d’informations sur le suivi, consultez Visualisez les invocations de fonctions Lambda à l'aide de AWS X-Ray.
Ajout d’une file d’attente de lettres mortes
Comme alternative à une destination réservée aux échecs, vous pouvez configurer votre fonction avec une file d’attente de lettres mortes pour enregistrer les événements ignorés en vue d’un traitement ultérieur. Une file d’attente de lettres mortes agit de la même manière qu’une destination réservée aux échecs en ce sens qu’elle est utilisée lorsqu’un événement échoue à toutes les tentatives de traitement ou expire sans être traité. Toutefois, vous ne pouvez ajouter ou supprimer une file d’attente de lettres mortes qu’au niveau de la fonction. Les versions de fonctions utilisent les mêmes paramètres de file d’attente de lettres mortes que la version non publiée ($LATEST). Les destinations réservées aux échecs prennent également en charge des cibles supplémentaires et incluent des détails sur la réponse de la fonction dans l’enregistrement d’invocation.
Pour retraiter les événements d’une file d’attente de lettres mortes, vous pouvez la définir comme source d’événements pour votre fonction Lambda. Vous pouvez également récupérer manuellement les événements.
Vous pouvez choisir une file d’attente Amazon SQS standard ou une rubrique Amazon SNS standanrd pour votre file d’attente de lettres mortes. Les files d’attente FIFO et les rubriques FIFO Amazon SNS ne sont pas prises en charge.
-
File d’attente Amazon SQS – Une file d’attente conserve les événements qui ont échoué jusqu’à ce qu’ils soient récupérés. Choisissez une file d'attente standard Amazon SQS si vous vous attendez à ce qu'une seule entité, telle qu'une fonction Lambda ou une CloudWatch alarme, traite l'événement défaillant. Pour de plus amples informations, veuillez consulter Utilisation de Lambda avec Amazon SQS.
-
Rubrique Amazon SNS – Une rubrique relaie les événements qui ont échoué vers une ou plusieurs destinations. Choisissez une rubrique Amazon SNS standard si vous voulez que plusieurs entités agissent sur un événement ayant échoué. Par exemple, vous pouvez configurer une rubrique pour envoyer des événements à une adresse e-mail, à une fonction Lambda ou à un point de terminaison HTTP. Pour de plus amples informations, veuillez consulter Invocation des fonctions Lambda à l’aide des notifications Amazon SNS.
Pour envoyer des événements à une file d’attente ou une rubrique, votre fonction a besoin d’autorisations supplémentaires. Ajoutez une stratégie avec les autorisations requises au rôle d’exécution de votre fonction. Si la file d'attente ou le sujet cible est chiffré à l'aide d'une AWS KMS clé gérée par le client, assurez-vous que le rôle d'exécution de votre fonction et la politique basée sur les ressources de la clé contiennent les autorisations appropriées.
Après avoir créé la cible et mis à jour votre rôle d’exécution de la fonction, ajoutez la file d’attente de lettres mortes à votre fonction. Vous pouvez configurer plusieurs fonctions pour envoyer des événements à la même cible.
Lambda envoie l’événement à la file d’attente de lettres mortes en l’état, avec des informations supplémentaires dans les attributs. Vous pouvez utiliser ces informations pour identifier l’erreur que la fonction a renvoyée ou établir une corrélation entre l’événement et des journaux ou une trace AWS X-Ray .
Attributs de message de file d’attente de lettres mortes
-
RequestID (Chaîne) – ID de la demande d’invocation. IDsLes demandes apparaissent dans les journaux des fonctions. Vous pouvez également utiliser le kit SDK X-Ray pour enregistrer l’ID de demande sur un attribut dans le suivi. Vous pouvez ensuite rechercher des suivis par ID de demande dans la console X-Ray.
-
ErrorCode(Numéro) — Le code d'état HTTP.
-
ErrorMessage(String) — Les 1 premiers Ko du message d'erreur.
Si Lambda ne parvient pas à envoyer de message à la file d'attente contenant des lettres mortes, il supprime l'événement et émet la métrique. DeadLetterErrors Cela peut se produire en raison d’un manque d’autorisations ou si la taille totale du message est supérieure à la limite de la file d’attente cible ou rubrique. Supposons, par exemple, qu’une notification Amazon SNS dont le corps est proche de 256 Ko déclenche une fonction qui génère une erreur. Dans ce cas, le message peut dépasser la taille maximale autorisée dans la file d’attente de lettres mortes en raison des données d’événement ajoutées par Amazon SNS et de attributs ajoutés par Lambda.
Si vous utilisez Amazon SQS en tant que source d’événement, configurez une file d’attente de lettres mortes sur la file d’attente Amazon SQS elle-même, non sur la fonction Lambda. Pour de plus amples informations, veuillez consulter Utilisation de Lambda avec Amazon SQS.
