Tester et déboguer les fonctions Lambda @Edge

Il est important de tester votre code de fonction Lambda @Edge de manière autonome, pour vous assurer qu'il exécute la tâche prévue, et de réaliser des tests d'intégration pour vous assurer que la fonction fonctionne correctement avec. CloudFront

Au cours des tests d'intégration ou après le déploiement de votre fonction, il se peut que vous deviez CloudFront corriger des erreurs, telles que des erreurs HTTP 5xx. Les erreurs peuvent être de différents types : une réponse non valide renvoyée par la fonction Lambda, des erreurs d'exécution lorsque la fonction est déclenchée, ou encore des erreurs en raison de la limitation d'exécution par le service Lambda. Les sections de cette rubrique donnent des stratégies pour déterminer le type de défaillance qui est à l'origine du problème, puis les étapes à suivre afin de résoudre le problème.

Note

Lorsque vous consultez des fichiers CloudWatch journaux ou des indicateurs pour résoudre des erreurs, sachez qu'ils sont affichés ou stockés à l'emplacement le Région AWS plus proche de l'endroit où la fonction s'est exécutée. Ainsi, si vous avez un site Web ou une application Web dont les utilisateurs se trouvent au Royaume-Uni et qu'une fonction Lambda est associée à votre distribution, par exemple, vous devez modifier la région pour afficher les CloudWatch métriques ou les fichiers journaux de Londres. Région AWS Pour plus d’informations, consultez Déterminez la région Lambda @Edge.

Testez vos fonctions Lambda @Edge

Il existe deux étapes pour tester votre fonction Lambda : le test autonome et le test d'intégration.

Test de la fonctionnalité autonome

Avant d'ajouter votre fonction Lambda à CloudFront, assurez-vous de la tester d'abord en utilisant les fonctionnalités de test de la console Lambda ou en utilisant d'autres méthodes. Pour plus d'informations sur les tests dans la console Lambda, voir Invoquer une fonction Lambda à l'aide de la console dans le manuel du développeur.AWS Lambda

Testez le fonctionnement de votre fonction dans CloudFront

Il est important de réaliser des tests d'intégration, dans lesquels votre fonction est associée à une distribution et s'exécute en fonction d'un CloudFront événement. Assurez-vous que la fonction est déclenchée pour le bon événement et renvoie une réponse valide et correcte pour CloudFront. Par exemple, assurez-vous que la structure de l'événement est correcte, que seuls les en-têtes valides sont inclus, etc.

Au fur et à mesure que vous testez l'intégration de votre fonction dans la console Lambda, reportez-vous aux étapes du didacticiel Lambda @Edge pour modifier votre code ou CloudFront le déclencheur qui appelle votre fonction. Par exemple, vérifiez que vous travaillez avec une version numérotée de votre fonction, comme le décrit cette étape du tutoriel : Étape 4 : ajouter un CloudFront déclencheur pour exécuter la fonction.

Lorsque vous apportez des modifications et que vous les déployez, sachez qu'il faudra plusieurs minutes pour que votre fonction et vos CloudFront déclencheurs mis à jour soient répliqués dans toutes les régions. Cela prend généralement quelques minutes, mais peut durer jusqu'à 15 minutes.

Vous pouvez vérifier si la réplication est terminée en accédant à la CloudFront console et en consultant votre distribution.

Pour vérifier si le déploiement de votre réplication est terminé

1. Ouvrez la CloudFront console à l'adressehttps://console.aws.amazon.com/cloudfront/v4/home.

2. Choisissez le nom de la distribution.

3. Vérifiez que le statut de distribution passe de En cours à Déployé, ce qui signifie que votre fonction a été répliquée. Suivez les étapes de la section suivante afin de vérifier que la fonction s'exécute correctement.

Sachez que les tests effectués dans la console valident uniquement la logique de votre fonction et n'appliquent pas de quotas (auparavant appelés limites) de service spécifiques à Lambda@Edge.

Identifiez les erreurs de fonction Lambda @Edge dans CloudFront

Une fois que vous avez vérifié que la logique de votre fonction fonctionne correctement, des erreurs HTTP 5xx peuvent encore s'afficher lors de l'exécution de votre fonction. CloudFront Les erreurs HTTP 5xx peuvent être renvoyées pour diverses raisons, notamment des erreurs liées à la fonction Lambda ou d'autres problèmes. CloudFront

• Si vous utilisez les fonctions Lambda @Edge, vous pouvez utiliser les graphiques de la CloudFront console pour identifier la cause de l'erreur, puis essayer de la corriger. Par exemple, vous pouvez voir si les erreurs HTTP 5xx sont causées par CloudFront ou par des fonctions Lambda, puis, pour des fonctions spécifiques, vous pouvez consulter les fichiers journaux associés afin d'étudier le problème.

• Pour résoudre les erreurs HTTP en général dans CloudFront, consultez les étapes de résolution des problèmes décrites dans la rubrique suivante :Résolution des réponses d’erreur de votre origine.

Quelles sont les causes des erreurs de fonction Lambda @Edge dans CloudFront

Il existe plusieurs raisons pour lesquelles une fonction Lambda peut entraîner une erreur HTTP 5xx. Les étapes de résolution à suivre dépendent du type d'erreur. Les erreurs peuvent être classées comme suit :

Une erreur d'exécution de la fonction Lambda

Une erreur d'exécution se produit lorsque Lambda CloudFront ne reçoit pas de réponse en raison d'exceptions non gérées dans la fonction ou d'une erreur dans le code. Par exemple, si le code comprend le rappel (Error).

Une réponse de fonction Lambda non valide est renvoyée à CloudFront

Une fois la fonction exécutée, CloudFront reçoit une réponse de Lambda. Une erreur est renvoyée si la structure d'objet de la réponse n'est pas conforme à Structure d'événement Lambda@Edge ou si la réponse contient des en-têtes ou d'autres champs non valides.

L'exécution dans CloudFront est limitée en raison des quotas de service Lambda (anciennement appelés limites)

Le service Lambda limite les exécutions dans chaque région, et renvoie une erreur si vous dépassez le quota. Pour plus d’informations, consultez Quotas sur Lambda@Edge.

Comment déterminer le type d'échec

Pour vous aider à décider sur quoi vous concentrer lorsque vous débugez et que vous vous efforcez de résoudre les erreurs renvoyées CloudFront, il est utile de déterminer pourquoi une erreur HTTP CloudFront est renvoyée. Pour commencer, vous pouvez utiliser les graphiques fournis dans la section Surveillance de la CloudFront console sur le AWS Management Console. Pour plus d'informations sur l'affichage des graphiques dans la section Surveillance de la CloudFront console, consultezSurveillez CloudFront les métriques avec Amazon CloudWatch.

Les graphiques suivants peuvent être particulièrement utiles lorsque vous souhaitez retracer si des erreurs sont renvoyées par les origines ou par une fonction Lambda, et pour réduire le type de problème lorsqu'il s'agit d'une erreur provenant d'une fonction Lambda.

Graphique des taux d'erreurs

L'un des graphiques que vous pouvez afficher dans l'onglet Présentation pour chacune de vos distributions est un graphique de taux d'erreurs. Ce graphique affiche le taux d'erreurs sous forme de pourcentage du nombre total de demandes adressées à votre distribution. Ce graphique montre le taux d'erreurs total, le total des erreurs 4xx, le total des erreurs 5xx et le total des erreurs 5xx provenant des fonctions Lambda. Selon le type d'erreur et le volume, vous pouvez prendre des mesures pour étudier et résoudre le problème initial.

• Si vous voyez des erreurs Lambda, vous pouvez poursuivre vos investigations en examinant les types d'erreurs spécifiques que la fonction renvoie. L'onglet Lambda@Edge errors (Erreurs Lambda@Edge) inclut des graphiques qui classent les erreurs de fonction par type pour vous aider à identifier le problème pour une fonction spécifique.

• Si vous CloudFront constatez des erreurs, vous pouvez les résoudre et vous efforcer de corriger les erreurs d'origine ou de modifier votre CloudFront configuration. Pour plus d’informations, consultez Résolution des réponses d’erreur de votre origine.

Graphiques des erreurs d'exécution et des réponses de fonction non valide

L'onglet Lambda@Edge errors (Erreurs Lambda@Edge) inclut des graphiques permettant de classer les erreurs Lambda@Edge pour une distribution spécifique, par type. Par exemple, un graphique montre toutes les erreurs d'exécution par Région AWS.

Pour faciliter la résolution des problèmes, vous pouvez rechercher des problèmes spécifiques en ouvrant et en examinant les fichiers journaux pour des fonctions spécifiques par région.

Pour afficher les fichiers journaux d'une fonction spécifique par région

1. Dans l'onglet Erreurs Lambda @Edge, sous Fonctions Lambda @Edge associées, choisissez le nom de la fonction, puis choisissez Afficher les métriques.

2. Ensuite, sur la page portant le nom de votre fonction, dans le coin supérieur droit, choisissez Afficher les journaux des fonctions, puis choisissez une région.

   Par exemple, si vous voyez des problèmes dans le graphique des erreurs pour la région USA Ouest (Oregon), sélectionnez cette région dans la liste déroulante. Cela ouvre la CloudWatch console Amazon.

3. Dans la CloudWatch console de cette région, sous Log streams, choisissez un log stream pour afficher les événements liés à la fonction.

De plus, lisez les sections suivantes de ce chapitre pour plus de recommandations sur le dépannage et la correction des erreurs.

Graphique des limitations

L'onglet Lambda@Edge errors (Erreurs Lambda@Edge) inclut également un graphique Throttles (Limitations). Occasionnellement, le service Lambda limite vos appels de fonction par région si vous atteignez le quota (auparavant appelé limite) de simultanéité régionale. Si vous voyez une erreur de dépassement de limite, cela signifie que votre fonction a atteint un quota que le service Lambda impose sur les exécutions dans une région. Pour obtenir plus d'informations sur ces limites et découvrir comment demander une augmentation du quota, veuillez consulter Quotas sur Lambda@Edge.

Pour obtenir un exemple sur la façon d'utiliser ces informations pour résoudre des erreurs HTTP, consultez le billet de blog Four steps for debugging your content delivery on AWS.

Résoudre les problèmes liés aux réponses non valides à la fonction Lambda @Edge (erreurs de validation)

Si vous identifiez que votre problème est une erreur de validation Lambda, cela signifie que votre fonction Lambda renvoie une réponse non valide à. CloudFront Suivez les instructions de cette section pour prendre les mesures nécessaires pour revoir votre fonction et vous assurer que votre réponse est conforme aux CloudFront exigences.

CloudFront valide la réponse d'une fonction Lambda de deux manières :

• La réponse Lambda doit se conformer à la structure d'objet requise. Voici des exemples de mauvaise structure d'objet : impossible d'analyser JSON, champs obligatoires manquants et la réponse contient un objet non valide. Pour plus d’informations, consultez le Structure d'événement Lambda@Edge.

• La réponse doit inclure uniquement les valeurs d'objet valides. Une erreur se produit si la réponse inclut un objet valide mais dont les valeurs ne sont pas prises en charge. Les exemples incluent les éléments suivants : ajout ou mise à jour d'en-têtes non autorisés ou en lecture seule (voir Restrictions sur les fonctions périphériques), dépassement des limitations de taille du corps (voir Limites sur la taille de la réponse générée dans la rubrique Lambda@Edge Erreurs) et les caractères ou les valeurs non valables (voir Structure d'événement Lambda@Edge).

Lorsque Lambda renvoie une réponse non valide à CloudFront, des messages d'erreur sont écrits CloudWatch dans des fichiers journaux qui sont CloudFront redirigés vers la région où la fonction Lambda a été exécutée. C'est le comportement par défaut auquel envoyer les fichiers journaux en CloudWatch cas de réponse non valide. Toutefois, si vous avez associé une fonction Lambda à une fonction Lambda CloudFront avant son lancement, il est possible qu'elle ne soit pas activée pour votre fonction. Pour plus d'informations, consultez la section Déterminer si votre compte transmet les journaux CloudWatch plus loin dans cette rubrique.

CloudFront envoie les fichiers journaux vers la région correspondant à l'endroit où votre fonction a été exécutée, dans le groupe de journaux associé à votre distribution. Les groupes de journaux ont le format suivant :/aws/cloudfront/LambdaEdge/DistributionId, où DistributionIdest l'ID de votre distribution. Pour déterminer la région dans laquelle se trouvent les fichiers CloudWatch journaux, consultez la section Détermination de la région Lambda @Edge plus loin dans cette rubrique.

Si l'erreur est reproductible, vous pouvez créer une nouvelle demande qui entraîne l'erreur, puis rechercher l'identifiant de la demande dans une CloudFront réponse ayant échoué (X-Amz-Cf-Iden-tête) afin de localiser un seul échec dans les fichiers journaux. L'entrée du fichier journal inclut des informations susceptibles de vous aider à identifier les raisons pour lesquelles l'erreur est renvoyée, et affiche aussi l'ID de demande Lambda correspondant, ce qui vous permet d'analyser la cause première dans le cadre d'une seule demande.

Si une erreur est intermittente, vous pouvez utiliser les journaux d' CloudFront accès pour trouver l'identifiant d'une demande qui a échoué, puis rechercher dans CloudWatch les journaux les messages d'erreur correspondants. Pour plus d'informations, consultez la section précédente, Détermination du type d'échec.

Résoudre les erreurs d'exécution de la fonction Lambda @Edge

Si le problème provient d'une erreur d'exécution Lambda, il peut être utile de créer des instructions de journalisation pour les fonctions Lambda, d'écrire des messages dans des fichiers CloudWatch journaux qui surveillent l'exécution de votre fonction CloudFront et déterminent si elle fonctionne comme prévu. Vous pouvez ensuite rechercher ces instructions dans les fichiers CloudWatch journaux pour vérifier que votre fonction fonctionne.

Note

Même si vous n'avez pas modifié votre fonction Lambda@Edge, les mises à jour de l'environnement d'exécution de la fonction Lambda peuvent l'affecter et renvoyer une erreur d'exécution. Pour plus d'informations sur les tests et la migration vers une version ultérieure, consultez Prochaines mises à jour de l'environnement d'exécution AWS Lambda et AWS Lambda @Edge.

Déterminez la région Lambda @Edge

Pour connaître les régions dans lesquelles votre fonction Lambda @Edge reçoit du trafic, consultez les métriques de la fonction sur la CloudFront console du. AWS Management Console Les statistiques sont affichées pour chaque AWS région. Sur la même page, vous pouvez choisir une région et afficher les fichiers journaux pour cette région afin de pouvoir rechercher des problèmes. Vous devez consulter les fichiers CloudWatch journaux dans la AWS région appropriée pour voir les fichiers journaux créés lors de l' CloudFront exécution de votre fonction Lambda.

Pour plus d'informations sur l'affichage des graphiques dans la section Surveillance de la CloudFront console, consultezSurveillez CloudFront les métriques avec Amazon CloudWatch.

Déterminez si votre compte envoie les journaux vers CloudWatch

Par défaut, CloudFront active la journalisation des réponses de fonction Lambda non valides et envoie les fichiers journaux vers CloudWatch . Rôles liés à un service pour Lambda@Edge Si vous avez ajouté des fonctions Lambda @Edge CloudFront avant la publication de la fonctionnalité de journal des réponses des fonctions Lambda non valide, la journalisation est activée lors de la prochaine mise à jour de votre configuration Lambda @Edge, par exemple en ajoutant un déclencheur. CloudFront

Vous pouvez vérifier que le transfert des fichiers journaux vers CloudWatch est activé pour votre compte en procédant comme suit :

• Vérifiez si les journaux apparaissent dans CloudWatch — Assurez-vous de regarder dans la région où la fonction Lambda @Edge s'est exécutée. Pour plus d’informations, consultez Déterminez la région Lambda @Edge.

• Déterminez si le rôle lié au service associé existe dans votre compte dans IAM — Vous devez avoir le rôle AWSServiceRoleForCloudFrontLogger IAM dans votre compte. Pour plus d’informations sur ce rôle, consultez Rôles liés à un service pour Lambda@Edge.