Détectez les erreurs et confirmez le rétablissement

Introduction

Créez une alarme de requêtes, publiez un profil invalide puis restaurez la page et le statut OK.

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

Vue d’ensemble

Configurer l’alarme d’erreurs

Dans cette étape, vous observerez les requêtes réelles. Ouvrez le site sain. Une métrique mesure une valeur dans le temps ; namespace regroupe et dimensions identifient l’application. Errors dans LabEx/Portfolio, Application=portfolio, reçoit 1 pour échec et 0 pour succès. Une alarme compare à un seuil et ne répare rien. La métrique Errors de cet exercice mesure uniquement les requêtes de page /website. Les images et autres fichiers produisent des événements de log séparés.

Entrez dans le projet.

cd /home/labex/project

Chargez et affichez l’instance.

source website.env
echo "$INSTANCE_ID"

Lisez Sum, Period=10, EvaluationPeriods=1 et GreaterThanThreshold avec seuil 0. missing ne considère pas l’absence de données comme trafic sain. L’intégration publie des métriques personnalisées à résolution d’une seconde ; aucune notification n’est configurée.

cat website-alarm.json

Créez l’alarme depuis le fichier.

aws cloudwatch put-metric-alarm --cli-input-json file://website-alarm.json

Consultez son état.

aws cloudwatch describe-alarms --alarm-names portfolio-errors

INSUFFICIENT_DATA peut être initial : pas encore assez de données évaluées. AWS View montre le même état. Ne le forcez pas manuellement.

Observer une mauvaise publication

Dans cette étape, vous reproduirez un profil invalide sans changer réseau ou autorisations.

Lisez le JSON invalide fourni.

cat profile-broken.json

Publiez-le au chemin du profil par SCP.

scp -F ssh_config profile-broken.json ubuntu@"$PUBLIC_IP":/home/ubuntu/portfolio/profile.json

Actualisez : Website unavailable tandis qu’EC2 reste running. Cherchez path=/website status=503 et reliez-le à la récente publication. 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=503"'

Attendez un cycle de dix secondes ; refaites une requête en échec si nécessaire puis lisez l’alarme.

aws cloudwatch describe-alarms --alarm-names portfolio-errors

Confirmez ALARM. S’il manque des données, produisez une nouvelle requête et laissez l’évaluation se terminer. Un ancien log ne constitue pas une mesure récente.

Rétablir et confirmer le résultat

Dans cette étape, vous restaurerez un profil valide puis vérifierez page et alarme.

Lisez les trois champs valides du fichier connu.

cat profile-working.json

Publiez au même chemin.

scp -F ssh_config profile-working.json ubuntu@"$PUBLIC_IP":/home/ubuntu/portfolio/profile.json

Actualisez pour voir Alex Morgan et l’image S3, puis trouvez une requête récente path=/website status=200. 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=200"'

Laissez un nouveau cycle de trafic sain s’évaluer ; actualisez si nécessaire et consultez l’alarme.

aws cloudwatch describe-alarms --alarm-names portfolio-errors

Confirmez OK. Les anciens 503 restent dans l’historique. Sans requêtes, missing peut rendre INSUFFICIENT_DATA, différent d’un trafic sain prouvé ; gardez les succès récents pendant la vérification.

Nettoyer les ressources de supervision

Dans cette étape, vous nettoierez après avoir confirmé le rétablissement.

Terminez l’instance.

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

Attendez terminated.

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

Supprimez uniquement portfolio-errors.

aws cloudwatch delete-alarms --alarm-names portfolio-errors

Supprimez le groupe de l’exercice.

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

Gardez S3, rôle, réseau et événements de référence. Supprimer l’alarme ne supprime pas les métriques ; le workload arrêté ne produit plus de nouvelles requêtes. Continuez avec AWS Resource Management for Beginners.

Résumé

Vous avez constaté HTTP 503 et ALARM puis restauré le profil pour retrouver HTTP 200 et OK, avant nettoyage.

Références officielles : CloudWatch alarms, high-resolution custom metrics.