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

• Utilisez la page des détails des scripts Canary pour trouver plus d'informations. Dans la CloudWatch console, choisissez Canaries dans le volet de navigation, puis choisissez le nom du canari pour ouvrir la page de détails du canari. Dans l'onglet Disponibilité, vérifiez la SuccessPercentmétrique pour voir si le problème est constant ou intermittent.

  Toujours dans l'onglet Availability (Disponibilité), choisissez un point de données ayant échoué pour afficher les captures d'écran, les journaux et les rapports d'étape (le cas échéant) de cette exécution ayant échoué.

  Si un rapport d'étape est disponible car les étapes font partie de votre script, vérifiez l'étape qui a échoué et consultez les captures d'écran associées pour voir le problème rencontré par vos clients.

  Vous pouvez également vérifier les HAR fichiers pour voir si une ou plusieurs demandes échouent. Vous pouvez aller plus loin en utilisant les journaux pour explorer les demandes ayant échoué et les erreurs. Enfin, vous pouvez comparer ces artefacts avec les artefacts d'une exécution de script canary réussie pour identifier le problème.

  Par défaut, CloudWatch Synthetics capture des captures d'écran pour chaque étape d'un canari d'interface utilisateur. Toutefois, votre script peut être configuré de manière à désactiver les captures d'écran. Pendant le débogage, vous devrez peut-être activer à nouveau les captures d'écran. De même, pour les API canaris, vous souhaiterez peut-être voir les en-têtes et le corps des HTTP demandes et des réponses pendant le débogage. Pour plus d'informations sur la manière d'inclure ces données dans le rapport, consultez executeHttpStep(stepNamerequestOptions, [rappel], [stepConfig]).

• S'il y a eu un déploiement récent dans votre application, annulez-le, puis déboguez plus tard.

• Connectez-vous manuellement à votre point de terminaison pour voir si vous pouvez reproduire le même problème.

Rubriques

• Canary échoue après la mise à jour de l'environnement Lambda
• Mon canari est bloqué par AWS WAF
• Attente de l'apparition d'un élément
• Le nœud n'est pas visible ou n'est pas un HTMLElement for page.click ()
• Impossible de télécharger des artefacts dans S3 (Exception : Unable to fetch S3 bucket location: Access Denied)
• Erreur : erreur de protocole (exécution). callFunctionOn) : Cible fermée.
• Canary Failed. Error: No datapoint – Le script Canary affiche une erreur de dépassement de délai d'attente
• Tentative d'accès à un point de terminaison interne
• Problèmes de mise à niveau et de rétrogradation des versions d'exécution des scripts Canary
• Problème de partage de demandes d'origine croisée (CORS)
• Problèmes de condition de la race Canary
• Résolution des problèmes liés à un Canary sur un VPC

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 régler le mode manuel à l'aide de AWS CLI ou en utilisant la console Lambda, en suivant les étapes ci-dessous dans les sections suivantes.

Avertissement

Lorsque vous modifiez les paramètres d'exécution en mode manuel, votre fonction Lambda ne reçoit pas de mises à jour de sécurité automatiques tant qu'elle n'est pas revenue en mode automatique. Au cours de cette période, votre fonction Lambda peut être vulnérable à des failles de sécurité.

Prérequis

• Installer jq

• Installez la dernière version du AWS CLI Pour de plus amples informations, veuillez consulter .AWS CLI instructions d'installation et de mise à jour.

É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 soit le 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"

Pour passer un Canary en mode manuel à l'aide de la console Lambda

1. Ouvrez le fichier AWS Lambda console à https://console.aws.amazon.com/lambda/.

2. Choisissez l'onglet Versions, choisissez le lien du numéro de version qui correspond à votreARN, puis cliquez sur l'onglet Code.

3. Faites défiler la page jusqu'à Paramètres d'exécution, développez la configuration de gestion du temps d'exécution et copiez la version d'exécution ARN.

   

4. Choisissez Modifier la configuration de gestion d'exécution, choisissez Manuel, collez la version d'exécution ARN que vous avez copiée précédemment dans le ARN champ Version d'exécution. Ensuite, choisissez Save (Enregistrer).

   

Mon canari est bloqué par AWS WAF

Pour prévenir AWS WAF pour ne pas bloquer votre canari, configurez un AWS WAF condition de correspondance de chaîne qui autorise la chaîneCloudWatchSynthetics. Pour plus d'informations, consultez la section Utilisation des conditions de correspondance de chaînes dans le AWS WAF .

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 :

• Vérifiez que le IAM rôle du canari dispose de l's3:ListAllMyBucketsautorisation, de l's3:GetBucketLocationautorisation pour le compartiment Amazon S3 approprié et de l's3:PutObjectautorisation pour le compartiment dans lequel le canari stocke ses artefacts. Si le script Canary effectue une surveillance visuelle, le rôle a également besoin de l'autorisation s3:GetObject pour le compartiment. Ces mêmes autorisations sont également requises dans la politique relative aux terminaux Amazon VPC S3 Gateway, si le Canary est déployé dans un environnement VPC doté d'un point de VPC terminaison.

• Si le canari utilise un AWS KMS clé de chiffrement gérée par le client au lieu de la clé standard AWS clé gérée (par défaut), le IAM rôle du canari n'est peut-être pas autorisé à chiffrer ou à déchiffrer à l'aide de cette clé. Pour de plus amples informations, veuillez consulter Chiffrement des artefacts de script Canary.

• Votre politique de compartiment peut ne pas autoriser le mécanisme de chiffrement utilisé par le script Canary. Par exemple, si votre politique de compartiment impose l'utilisation d'un mécanisme ou d'une KMS clé de chiffrement spécifique, vous devez sélectionner le même mode de chiffrement pour votre Canary.

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.

Pour utiliser CloudWatch les journaux pour voir les journaux d'un canari

1. Ouvrez la CloudWatch console à l'adresse https://console.aws.amazon.com/cloudwatch/.

2. Dans le panneau de navigation de gauche, choisissez Log groups (Groupes de journaux).

3. Recherchez le groupe de journaux en saisissant le nom du script Canary dans la zone de filtre. Les groupes de logs pour canaris portent le nom /aws/lambda/cwsyn-canaryName-randomId.

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.

Note

Lorsque vous envisagez de mettre à niveau ou de rétrograder la version d'exécution d'un Canary, nous vous recommandons de cloner d'abord le Canary et de mettre à jour la version d'exécution dans le Canary cloné. Une fois que vous avez vérifié que le clone fonctionne avec la nouvelle version d'exécution, vous pouvez mettre à jour la version d'exécution de votre script Canary d'origine et supprimer le clone.

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.

Note

Vous pouvez remplacer les paramètres de lancement utilisés par CloudWatch Synthetics lorsque vous utilisez la version d'exécution ou une version ultérieure. syn-nodejs-2.1

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