Présentation

La Compréhension de la résolution des problèmes à l'aide de CloudFront permet aux opérateurs et aux SRE de corriger rapidement les erreurs qui peuvent survenir à différents endroits de l'application Web : CloudFront, les fonctions de périphérie ou l'origine. Parmi ces erreurs, nous pouvons citer une origine surchargée renvoyant des erreurs 5xx, l'impossibilité pour CloudFront de se connecter à l'origine ou l'échec de l'exécution de Lambda@Edge suite à une exception non gérée dans son code.

Traçage des demandes des utilisateurs jusqu'à leur origine

CloudFront génère un identifiant de demande unique pour chaque demande traitée. Il est recommandé de suivre la demande à l'aide de son identifiant au fur et à mesure qu'elle circule dans la pile d'applications :

  • CloudFront ajoute un en-tête x-amz-cf-id qui contient l'identifiant de la demande lorsqu'il renvoie la réponse à une demande HTTP.
  • CloudFront inclut l'identifiant de la demande dans le champ x-edge-request-id de l'enregistrement généré pour la demande dans les journaux d'accès. Si une WebACL AWS WAF est attachée à la distribution CloudFront, le WAF inclut l'identifiant de demande dans le champ requestId de l'enregistrement de journal généré pour la demande dans les journaux WAF. Par exemple, OLX a créé un chat box qui peut être utilisé par ses ingénieurs du support client dans Slack pour interroger une demande spécifique à partir de son identifiant de demande dans les journaux WAF afin de comprendre pourquoi elle a été bloquée, puis de répondre plus rapidement aux tickets des clients au quotidien.
  • Si une fonction de périphérie est configurée sur la distribution CloudFront, l'identifiant de demande est mis à la disposition de la fonction dans le champ requestId de l'objet d'événement, à la fois pour (les fonctions CloudFront et Lambda@Edge).
  • En cas d'absence de cache, lorsque CloudFront transmet la demande à l'origine, il ajoute l'en-tête x-amz-cf-id à la demande, avec la valeur de l'identifiant de demande. Il est recommandé d'enregistrer cet en-tête sur vos serveurs d'origine.

Dépannage des erreurs à l'aide de CloudFront

Lorsque vos systèmes de surveillance (par exemple, les alarmes CloudWatch) détectent une augmentation du nombre de réponses avec des erreurs 4xx ou 5xx, vous devez déterminer le type d'erreur et l'endroit où elle se produit pour y remédier.

Pour ce faire, filtrez les journaux d'accès de CloudFront sur les enregistrements générant un code d'erreur, et consultez les champs de journal x-edge-result-type, x-edge-response-result-type et x-edge-detailed-result-type pour mieux comprendre le problème. L'analyse des journaux d'accès dépend de l'endroit où vous les stockez. Une approche très simple consiste à interroger les journaux stockés dans S3 à l'aide d'Athena avec des requêtes SQL standard. À titre d'exemple, la requête SQL suivante filtre les journaux pour détecter les erreurs 5xx dans une plage de dates spécifique, limitée aux 100 premiers enregistrements.

SÉLECTIONNER * COMME nombre À PARTIR DE cloudfront_logs
OÙ le statut est >= 500 ET « date » ENTRE LE « 09/06/2022 » ET LE « 10/06/2022 »
LIMITE 100 ;


Dans certains cas, consultez les journaux de WAF ou de CloudFront pour obtenir des informations supplémentaires sur le dépannage. Par exemple, les journaux AWS WAF peuvent expliquer pourquoi une demande donnée a été bloquée. Un autre exemple est la vérification des journaux des fonctions de périphérie dans CloudWatch Logs pour comprendre une erreur d'exécution ayant entraîné une erreur 5xx. Enfin, il est recommandé de comprendre comment CloudFront met en cache les erreurs afin de savoir quand une réponse d'erreur est renvoyée par le cache CloudFront ou non.

Résolution des problèmes de latence à l'aide de CloudFront

Lorsque vos systèmes de surveillance (par exemple, les alarmes CloudWatch sur la latence d'Origin et les mesures du taux d'accès au cache) détectent une augmentation des latences de réponse, vous devez comprendre où se situe le goulot d'étranglement lié à la latence pour y remédier. Pour cela, pensez à analyser les champs de latence dans les journaux d'accès de CloudFront. Prenez en compte les champs suivants :

  • délai jusqu'au premier octet : latence du premier octet entre CloudFront et le visualiseur, disponible dans les journaux standard et les journaux en temps réel
  • durée : latence du dernier octet entre CloudFront et le visualiseur, disponible dans les journaux standard et les journaux en temps réel
  • origin-fbl : latence du premier octet entre CloudFront et votre origine, disponible dans les journaux en temps réel
  • origin-lbl : latence du dernier octet entre CloudFront et votre origine, disponible dans les journaux en temps réel

Vous pouvez analyser ces champs en regroupant la requête SQL sur l'une des dimensions pertinentes, telle que l'URL ou le pays. Cela vous permet de réduire le problème de latence. En outre, vous pouvez trouver les mêmes informations côté client à l'aide des en-têtes de synchronisation du serveur de CloudFront, lorsqu'ils sont configurés dans la politique d'en-tête de réponse. L'en-tête de synchronisation du serveur ci-dessous explique que ma demande était un accès au cache sur le pop MRS52-P1 à Marseille, avec une latence descendante de 64 millisecondes au premier octet. Notez l'en-tête Age généré par CloudFront pour expliquer que ce contenu a été récupéré ou actualisé depuis l'origine pendant 61 secondes.

Résolution des problèmes de performance Web à l'aide de CloudWatch RUM

CloudWatch RUM vous permet de surveiller votre application côté client, en intégrant une balise javascript à vos pages Web. Le javascript collecte des données à partir des API du navigateur, telles que les temps de chargement des pages avec la ventilation des étapes de connexion (recherche DNS, connexion TCP, etc.) ou Google Core Web Vitals (LCP, FID, etc.), puis les envoie à CloudWatch RUM pour le tableau de bord. Vous pouvez analyser les performances de votre application en filtrant sur des dimensions spécifiques telles que le type de navigateur, le pays de l'utilisateur ou un identifiant de page spécifique.

Demande d'assistance auprès d'AWS Support

Dans les cas où vous avez besoin de l'assistance d'AWS Support pour résoudre plus en profondeur les problèmes d'erreurs ou de latences, ouvrez un ticket d'assistance qui inclut une liste d'identifiants de demande CloudFront correspondant à des demandes lentes ou à des demandes entraînant des erreurs. Grâce à ces identifiants de demande fournis, les ingénieurs du support peuvent consulter les journaux internes pour mieux comprendre le problème et vous fournir des recommandations sur la manière d'y remédier.

Surveillance des utilisateurs réels pour Amazon CloudWatch

Ressources

Cette page vous a-t-elle été utile ?

 Commentaires