Présentation du 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 de la capacité suffisante pour gérer toutes les requêtes entrantes, des événements peuvent attendre dans la file d’attente pendant des heures ou des jours 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 Ajout d’une file d’attente de lettres mortes.

• 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 Procédure de traitement par Lambda des 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 avec requêtes proxy d’un utilisateur ou client en amont peuvent également avoir une stratégie de nouvelle tentative ou relayer la réponse d’erreur au demandeur. Par exemple, API Gateway transmet toujours la réponse d’erreur au demandeur.

  Pour une invocation asynchrone, la logique de nouvelle tentative est la même, quelle que soit la source de l’invocation. Par défaut, Lambda réessaie une invocation asynchrone qui a échoué jusqu’à deux fois. Pour de plus amples informations, veuillez consulter Méthode de gestion des erreurs et nouvelles tentatives d’invocation asynchrone par Lambda.

• 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 protéger votre fonction de toute surcharge, envisagez de placer une couche d'API 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 rapidement et d'identifier les problèmes dans le code de votre fonction, de l'API ou d'autres ressources qui prennent en charge votre application. Pour de plus amples informations, veuillez consulter Surveillance et dépannage des fonctions Lambda.