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 la fonction Lambda ARN

Exécutez la commande suivante pour récupérer le EngineArn champ de la réponse. Il EngineArn s'agit ARN de la fonction Lambda associée au canari. Vous l'utiliserez 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 la dernière bonne version d'exécution de Lambda ARN

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 la version d'exécution Lambda a été ARN modifiée 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 la version ARN 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 rechercher celle ARN de la version d'exécution précédente. Enregistrez la version ARN 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 la version ARN 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 and qualifier avec respectivement le numéro de version de la fonction ARN Lambda et le numéro de version de la fonction Lambda, en utilisant les valeurs que vous avez trouvées à l'étape 1. Remplacez également le runtime-version-arn avec la version ARN que vous avez trouvée à 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 éviter AWS WAF de bloquer votre canari, configurez une condition de correspondance des AWS WAF chaînes qui autorise la chaîneCloudWatchSynthetics. Pour plus d'informations, consultez la section Utilisation des conditions de correspondance de chaînes dans la AWS WAF documentation.

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 HAR tels que des fichiers, 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 l'utiliser. VPC Pour de plus amples informations, veuillez consulter Faire courir un canari 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 Canary de la version d'exécution syn-1.0 à une version ultérieure, il se peut qu'il s'agisse d'un problème de partage de requêtes (CORS) d'origine croisée. Pour de plus amples informations, veuillez consulter Problème de partage de demandes d'origine croisée (CORS).

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 de partage de demandes d'origine croisée (CORS)

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 tel est le cas, l'échec des demandes réseau peut être dû à des restrictions de partage de demandes d'origine croisée (CORS). Vous pouvez vérifier si tel est le cas en désactivant le suivi actif ou en supprimant les HTTP en-têtes 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 CORS vérification des XMLHttpRequest requêtes (). 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.

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 canaris peuvent rencontrer des conditions de course lorsque le canari interagit avec la même ressource lors de différentes courses.