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.

Dépannage d'un script Canary ayant échoué

Si votre script Canary échoue, vérifiez les points suivants pour le dépannage.

Résolution de problème généraux

Canary échoue après la mise à jour de l'environnement Lambda

CloudWatch Les canaris Synthetics sont implémentés sous forme de fonctions Lambda dans votre compte. Ces fonctions Lambda font l'objet de mises à jour régulières du runtime Lambda contenant des mises à jour de sécurité, des corrections de bogues et d'autres améliorations. Lambda s'efforce de fournir des mises à jour d'exécution rétrocompatibles avec les fonctions existantes. Cependant, comme pour les correctifs logiciels, il existe de rares cas dans lesquels une mise à jour de l’environnement d’exécution peut avoir un impact négatif sur une fonction existante. Si vous pensez que votre Canary a été affecté par une mise à jour du runtime Lambda, vous pouvez utiliser le mode manuel de gestion du runtime Lambda (dans les régions prises en charge) pour annuler temporairement la version d'exécution Lambda. Cela permet à votre fonction Canary de fonctionner et de minimiser les perturbations, ce qui vous laisse le temps de remédier à l'incompatibilité avant de revenir à la dernière version d'exécution.

Si votre Canary échoue après une mise à jour de l'environnement d'exécution Lambda, la meilleure solution consiste à passer à l'un des derniers environnements d'exécution Synthetics. Pour plus d'informations sur les derniers environnements d'exécution, consultezVersions d'exécution Synthetics.

Comme solution alternative, dans les régions où les contrôles de gestion d'exécution Lambda sont disponibles, vous pouvez rétablir un environnement d'exécution géré par Lambda sur un canary, en utilisant le mode manuel pour les contrôles de gestion d'exécution. Vous pouvez définir le mode manuel à l'aide de la console Lambda AWS CLI ou à l'aide de celle-ci, en suivant les étapes ci-dessous dans les sections suivantes.

Prérequis

Étape 1 : Obtenir l'ARN de la fonction Lambda

Exécutez la commande suivante pour récupérer le EngineArn champ de la réponse. Il EngineArn s'agit de l'ARN de la fonction Lambda associée au canari. Vous allez utiliser cet ARN dans les étapes suivantes.

aws synthetics get-canary --name my-canary | jq '.Canary.EngineArn'

Exemple de sortie de EngingArn :

"arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8"

Étape 2 : Obtenir le dernier ARN valide de la version d'exécution Lambda

Pour savoir si votre Canary a été impacté par une mise à jour de l'environnement d'exécution Lambda, vérifiez si la date et l'heure auxquelles l'ARN de la version d'exécution Lambda a changé dans vos journaux correspondent à la date et à l'heure auxquelles vous avez constaté un impact sur votre Canary. S'ils ne correspondent pas, ce n'est probablement pas une mise à jour du moteur d'exécution Lambda qui est à l'origine de vos problèmes.

Si votre Canary est concerné par une mise à jour du moteur d'exécution Lambda, vous devez identifier l'ARN de la version fonctionnelle du moteur d'exécution Lambda que vous utilisiez auparavant. Suivez les instructions de la section Identification des modifications de version d'exécution pour trouver l'ARN de la version d'exécution précédente. Enregistrez l'ARN de la version d'exécution et passez à l'étape 3 pour définir la configuration de gestion de l'exécution.

Si votre Canary n'a pas encore été affecté par une mise à jour de l'environnement Lambda, vous pouvez trouver l'ARN de la version d'exécution Lambda que vous utilisez actuellement. Exécutez la commande suivante pour récupérer RuntimeVersionArn la fonction Lambda à partir de la réponse.

aws lambda get-function-configuration \
--function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991:8" | jq '.RuntimeVersionConfig.RuntimeVersionArn'

Exemple de sortie de RuntimeVersionArn :

"arn:aws:lambda:us-west-2::runtime:EXAMPLE647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Étape 3 : mise à jour de la configuration de gestion du runtime Lambda

Vous pouvez utiliser la console Lambda AWS CLI ou la console Lambda pour mettre à jour la configuration de gestion de l'exécution.

Pour définir le mode manuel de configuration de la gestion des environnements d'exécution Lambda à l'aide du AWS CLI

Entrez la commande suivante pour passer en mode manuel de la gestion de l'exécution de la fonction Lambda. Assurez-vous de remplacer le function-name et qualifier par l'ARN de la fonction Lambda et le numéro de version de la fonction Lambda respectivement, en utilisant les valeurs que vous avez trouvées à l'étape 1. Remplacez également le runtime-version-arn par l'ARN de version que vous avez trouvé à l'étape 2.

aws lambda put-runtime-management-config \
    --function-name "arn:aws:lambda:us-west-2:123456789012:function:cwsyn-my-canary-dc5015c2-db17-4cb5-afb1-EXAMPLE991" \
    --qualifier 8 \
    --update-runtime-on "Manual" \
    --runtime-version-arn "arn:aws:lambda:us-west-2::runtime:a993d90ea43647b82f490a45d7ddd96b557b916a30128d9dcab5f4972911ec0f"

Mon canari est bloqué par AWS WAF

Pour autoriser le trafic Canary AWS WAF, créez une condition de correspondance de AWS WAF chaîne qui autorise une chaîne personnalisée que vous spécifiez. Pour plus d'informations, consultez la section Utilisation des conditions de correspondance de chaînes dans la AWS WAF documentation.

Nous vous recommandons vivement d'utiliser votre propre chaîne d'agent utilisateur personnalisée au lieu d'utiliser les valeurs par défaut. Cela permet de mieux contrôler le AWS WAF filtrage et d'améliorer la sécurité.

Pour définir une chaîne d'agent utilisateur personnalisée, procédez comme suit :

Attente de l'apparition d'un élément

Après avoir analysé vos journaux et captures d'écran, si vous constatez que votre script attend qu'un élément apparaisse à l'écran et qu'il expire, vérifiez la capture d'écran appropriée pour voir si l'élément apparaît sur la page. Vérifiez votre xpath pour vous assurer qu'il est correct.

Pour les problèmes liés à Puppeteer, consultez la page de Puppeteer ou les forums Internet. GitHub

Le nœud n'est pas visible ou n'est pas un HTMLElement for page.click ()

Si un nœud n'est pas visible ou n'est pas un HTMLElement pour page.click(), vérifiez d'abord le xpath que vous utilisez pour cliquer sur l'élément. De plus, si votre élément se trouve en bas de l'écran, ajustez votre fenêtre d'affichage. CloudWatch Synthetics utilise par défaut une fenêtre d'affichage de 1920 x 1080. Vous pouvez définir une fenêtre d'affichage différente lorsque vous lancez le navigateur ou à l'aide de la fonction Puppeteer page.setViewport.

Impossible de télécharger des artefacts dans S3 (Exception : Unable to fetch S3 bucket location: Access Denied)

Si votre Canary échoue à cause d'une erreur Amazon S3, CloudWatch Synthetics n'a pas pu télécharger les captures d'écran, les journaux ou les rapports créés pour le Canary en raison de problèmes d'autorisation. Vérifiez les éléments suivants :

Si le script Canary effectue une surveillance visuelle, consultez Mise à jour de l'emplacement et du chiffrement des artefacts en utilisant la surveillance visuelle pour en savoir plus.

Erreur : erreur de protocole (exécution). callFunctionOn) : Cible fermée.

Cette erreur apparaît s'il y a des demandes réseau après la fermeture de la page ou du navigateur. Vous avez peut-être oublié d'attendre une opération asynchrone. Après avoir exécuté votre script, CloudWatch Synthetics ferme le navigateur. L'exécution de toute opération asynchrone après la fermeture du navigateur peut provoquer target closed error.

Canary Failed. Error: No datapoint – Le script Canary affiche une erreur de dépassement de délai d'attente

Cela signifie que l'exécution de votre script Canary a dépassé le délai d'attente. L'exécution de Canary s'est arrêtée avant que CloudWatch Synthetics puisse publier des indicateurs de réussite ou mettre à jour CloudWatch des artefacts tels que des fichiers HAR, des journaux et des captures d'écran. Si votre délai d'attente est trop court, vous pouvez l'augmenter.

Par défaut, la valeur de délai d'attente d'un script Canary est égale à sa fréquence. Vous pouvez ajuster manuellement la valeur du délai d'attente pour qu'elle soit inférieure ou égale à la fréquence du script Canary. Si la fréquence de votre script Canary est faible, vous devez l'augmenter pour augmenter le délai d'attente. Vous pouvez ajuster à la fois la fréquence et le délai d'expiration dans Schedule lorsque vous créez ou mettez à jour un Canary à l'aide de la console CloudWatch Synthetics.

Vérifiez que la valeur du délai d'attente de votre script canary n'est pas inférieure à 15 secondes pour permettre les démarrages à froid Lambda et le temps nécessaire pour démarrer l'instrumentation canary.

Les artefacts Canary ne peuvent pas être consultés dans la console CloudWatch Synthetics lorsque cette erreur se produit. Vous pouvez utiliser CloudWatch Logs pour voir les logs du canari.

Tentative d'accès à un point de terminaison interne

Si vous souhaitez que votre Canary accède à un point de terminaison de votre réseau interne, nous vous recommandons de configurer CloudWatch Synthetics pour utiliser le VPC. Pour de plus amples informations, veuillez consulter Exécution d'un script Canary sur un VPC.

Problèmes de mise à niveau et de rétrogradation des versions d'exécution des scripts Canary

Si vous avez récemment mis à niveau le script Canary de la version d'exécution syn-1.0 vers une version ultérieure, il peut s'agir d'un problème CORS (partage des demandes cross-origin). Pour de plus amples informations, veuillez consulter Problème CORS (partage des demandes cross-origin).

Si vous avez récemment rétrogradé Canary vers une ancienne version d'exécution, assurez-vous que les fonctions Synthetics que vous utilisez sont disponibles dans CloudWatch l'ancienne version d'exécution vers laquelle vous avez rétrogradé. Par exemple, la fonction executeHttpStep est disponible pour l'exécution syn-nodejs-2.2 et version ultérieure. Pour vérifier la disponibilité des fonctions, consultez Écriture d'un script Canary.

Problème CORS (partage des demandes cross-origin)

Dans un script Canary d'interface utilisateur, si certaines demandes réseau échouent avec une erreur 403 ou net::ERR_FAILED, vérifiez si le suivi actif est activé pour le script Canary et si ce dernier utilise également la fonction Puppeteer page.setExtraHTTPHeaders pour ajouter des en-têtes. Si c'est le cas, les demandes réseau peuvent échouer en raison de restrictions CORS (partage des demandes cross-origin). Vous pouvez confirmer si c'est le cas en désactivant le suivi actif ou en supprimant les en-têtes HTTP supplémentaires.

Pourquoi cela se produit-il ?

Lorsque le suivi actif est utilisé, un en-tête supplémentaire est ajouté à toutes les demandes sortantes pour suivre l'appel. La modification des en-têtes de requête en ajoutant un en-tête de trace ou en ajoutant des en-têtes supplémentaires à l'aide de Puppeteer page.setExtraHTTPHeaders entraîne une vérification CORS des XMLHttp requêtes Request (XHR).

Si vous ne souhaitez pas désactiver le suivi actif ou supprimer les en-têtes supplémentaires, vous pouvez mettre à jour votre application web pour autoriser l'accès cross-origin ou désactiver la sécurité web à l'aide de l'indicateur disable-web-security lorsque vous lancez le navigateur Chrome dans votre script.

Vous pouvez remplacer les paramètres de lancement utilisés par CloudWatch Synthetics et transmettre des paramètres d'indicateur disable-web-security supplémentaires à l'aide de la fonction de lancement de Synthetics. CloudWatch Pour de plus amples informations, veuillez consulter Fonctions de bibliothèque disponibles pour les scripts Canary Node.js utilisant Puppeteer.

Problèmes de condition de la race Canary

Pour une expérience optimale lors de l'utilisation de CloudWatch Synthetics, assurez-vous que le code écrit pour les canaris est idempotent. Sinon, dans de rares cas, les courses à canaris peuvent se heurter à des conditions de course lorsque le canari interagit avec la même ressource lors de différentes courses.

Dépannage d'un script Canary sur un VPC

Si vous rencontrez des problèmes après la création ou la mise à jour d'un script Canary sur un VPC, l'une des sections suivantes pourrait vous aider à résoudre le problème.

Nouveau script Canary en état d'erreur ou échec de mise à jour du script Canary

Si vous créez un script Canary à exécuter sur un VPC et qu'il obtient immédiatement un état d'erreur, ou si vous ne pouvez pas mettre à jour un script Canary à exécuter sur un VPC, le rôle du script Canary peut ne pas avoir les autorisations appropriées. Pour s'exécuter sur un VPC, un script Canary doit disposer des autorisations ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces et ec2:DeleteNetworkInterface. Ces autorisations sont toutes contenues dans la politique AWSLambdaVPCAccessExecutionRole gérée. Pour de plus amples informations, veuillez consulter Rôle d'exécution et autorisations utilisateur.

Si ce problème s'est produit lorsque vous avez créé un script Canary, vous devez supprimer le script Canary et en créer un nouveau. Si vous utilisez la CloudWatch console pour créer le nouveau canary, sous Autorisations d'accès, sélectionnez Créer un nouveau rôle. Un nouveau rôle est créé qui inclut toutes les autorisations requises pour exécuter le script Canary.

Si ce problème se produit lorsque vous mettez à jour un script Canary, vous pouvez à nouveau mettre à jour le script Canary et fournir un nouveau rôle qui dispose des autorisations requises.

Erreur de type « No test result returned » (aucun résultat de test retourné)

Si un script Canary affiche une erreur de type « aucun résultat de test retourné », l'un des problèmes suivants peut en être la cause :

Pour mieux résoudre ces problèmes, veuillez consulter les journaux pour le script Canary.

Résolution des problèmes liés à une nouvelle tentative automatique de Canary

Pour comprendre pourquoi votre Canary échoue ou pour analyser des tentatives infructueuses spécifiques, suivez ces étapes de résolution des problèmes.