Comprendre le comportement des nouvelles tentatives dans Lambda

Lorsque vous invoquez une fonction directement, vous déterminez la stratégie de gestion des erreurs liées au code de votre fonction. Lambda ne réessaie pas automatiquement ce type d'erreur en votre nom. Pour réessayer, vous pouvez manuellement invoquer à nouveau votre fonction, envoyer l'événement échoué à une file d'attente pour le débogage, ou ignorer l'erreur. Le code de votre fonction peut s'exécuter entièrement, partiellement ou pas du tout. Si vous recommencez, assurez-vous que le code de votre fonction peut gérer le même événement plusieurs fois, sans provoquer des transactions en double ou d’autres effets secondaires.

Lorsque vous appelez une fonction indirectement, vous devez connaître le comportement de la nouvelle tentative de l’appelant et tout service que la demande rencontre sur le chemin. Cela inclut les scénarios suivants.

• Appel asynchrone – Lambda réessaie deux fois les erreurs de fonction. Si la fonction ne dispose pas d'une capacité suffisante pour traiter toutes les demandes entrantes, les événements peuvent attendre des heures dans la file d'attente avant d'être envoyés à la fonction. Vous pouvez configurer une file d'attente de lettres mortes sur la fonction pour capturer les événements qui n'ont pas été traitées avec succès. Pour de plus amples informations, veuillez consulter Invocation d'une fonction Lambda de manière asynchrone.

• Mappages de source d'événement – Les mappages de source d'événement qui lisent à partir de flux réessaient la totalité du lot d'événements. Les erreurs répétées bloquent le traitement de la partition concernée jusqu'à la résolution de l'erreur ou l'expiration des éléments. Pour détecter des partitions bloquées, vous pouvez surveiller la métrique Âge de l'itérateur.

  Pour les mappages de source d'événement qui lisent à partir d'une file d'attente, vous devez déterminer l'intervalle entre les nouvelles tentatives et la destination pour les événements ayant échoué, en configurant le délai de visibilité et la stratégie de redirection dans la file d'attente source. Pour plus d'informations, consultez Comment Lambda traite les enregistrements provenant de sources d'événements basées sur des flux et des files d'attente ainsi que les rubriques spécifiques du service dans Invoquer Lambda avec des événements provenant d'autres services AWS.

• AWS services — AWS les services peuvent appeler votre fonction de manière synchrone ou asynchrone. Dans le cas des appels synchrones, le service décide s'il convient d'effectuer une nouvelle tentative. Par exemple, les opérations par lot Amazon S3 retentent l'opération si la fonction Lambda renvoie un code de réponse TemporaryFailure. Les services qui demandent par proxy à un utilisateur ou à un client en amont peuvent avoir une stratégie de nouvelle tentative ou peuvent transmettre la réponse d'erreur au demandeur. Par exemple, API Gateway transmet toujours la réponse d'erreur au demandeur.

  Pour un appel asynchrone, la logique de nouvelle tentative est la même quelle que soit la source d'appel. Par défaut, Lambda réessaie un appel asynchrone qui a échoué jusqu'à deux fois. Pour de plus amples informations, veuillez consulter Comment Lambda gère les erreurs et les nouvelles tentatives avec un appel asynchrone.

• Autres comptes et clients – Lorsque vous accordez l'accès à d'autres comptes, vous pouvez utiliser des stratégies basées sur une ressource afin de restreindre les services ou ressources qu'ils peuvent configurer pour appeler votre fonction. Pour éviter que votre fonction ne soit surchargée, pensez à placer une API couche devant votre fonction avec Amazon API Gateway.

Pour vous aider à gérer les erreurs dans les applications Lambda, Lambda s'intègre à des services tels qu'Amazon et. CloudWatch AWS X-Ray Vous pouvez utiliser une combinaison de journaux, de mesures, d'alarmes et de suivi pour détecter et identifier rapidement les problèmes liés à votre code de fonction ou à d'autres ressources prenant en charge votre application. API Pour de plus amples informations, veuillez consulter Surveillance et dépannage des fonctions Lambda.