Lisez les journaux des requêtes du site

AWSBeginner
Pratiquer maintenant

Introduction

Produisez des requêtes réelles et reliez les événements CloudWatch aux réponses HTTP 200 et 404.

Terminez les laboratoires précédents du portfolio. Cet environnement fournit ses propres ressources et les capacités antérieures nécessaires. Réutilisez les connaissances, pas les instances, fichiers ou identifiants précédents.

Lien avec la certification

Certification Tâches Pratique
AWS Certified Cloud Practitioner (CLF-C02) Task 3.8 Comprendre les réponses de l’application avec CloudWatch Logs.

Vue d’ensemble

Produisez des requêtes réelles et reliez les événements CloudWatch aux réponses HTTP 200 et 404.

Trouver une requête réussie

Dans cette étape, vous ouvrirez le portfolio et confirmerez Alex Morgan. Un log event décrit un événement daté ; le log group regroupe les événements et un log stream peut correspondre à une instance. L’intégration fournit chemin, statut et ID sans enregistrer clés ou en-têtes.

Entrez dans le projet.

cd /home/labex/project

Chargez et affichez LOG_GROUP.

source website.env
echo "$LOG_GROUP"

filter-log-events sans motif lit les événements collectés.

aws logs filter-log-events --log-group-name "$LOG_GROUP"

Trouvez path=/website status=200 : HTTP 200 signifie succès. timestamp est en millisecondes depuis Unix epoch et request_id distingue la requête. Le navigateur demande aussi /assets/aura-brand.webp. AWS View lit les mêmes événements ; la vérification prouve leur collecte, pas votre lecture.

Diagnostiquer une page absente

Dans cette étape, vous cliquerez Open a missing page. /missing affiche Page not found ; 404 indique une route absente, pas un serveur arrêté.

Filtrez 404 et trouvez path=/missing status=404. Le motif est une expression exacte : les guillemets simples extérieurs conservent les guillemets doubles intérieurs.

aws logs filter-log-events --log-group-name "$LOG_GROUP" --filter-pattern '"status=404"'

Revenez au portfolio, actualisez pour confirmer Alex Morgan puis lisez tous les événements.

aws logs filter-log-events --log-group-name "$LOG_GROUP"

Les événements montrent une route en échec et un site principal fonctionnel. Un redémarrage ne crée pas la route. Un résultat filtré vide n’est pas une preuve de succès : vérifiez lien, groupe et requête.

Point de contrôle réel du laboratoire ; vos identifiants peuvent varier.

Nettoyer site et journaux

Dans cette étape, vous supprimerez le serveur et seulement le groupe de l’exercice après lecture.

Affichez l’ID de l’instance.

echo "$INSTANCE_ID"

Terminez cette instance.

aws ec2 terminate-instances --instance-ids "$INSTANCE_ID"

Attendez terminated.

aws ec2 wait instance-terminated --instance-ids "$INSTANCE_ID"

Supprimez LOG_GROUP, ses streams et événements.

aws logs delete-log-group --log-group-name "$LOG_GROUP"

Préservez groupe de référence et réseau ; les événements de l’exercice disparaissent d’AWS View.

Résumé

Vous avez relié routes et événements réels, distingué page absente et serveur arrêté, puis nettoyé les journaux.

Références officielles : CloudWatch Logs concepts, filter pattern syntax.