Diagnostiquer un incident avec les journaux et les métriques

Introduction

Des commandes valides échouent tandis qu'une requête d'inventaire réussit. Vous allez comparer les métriques applicatives, tracer une requête échouée dans les journaux, corriger un petit défaut de configuration et confirmer le rétablissement sans effacer l'historique des échecs.

Terminez d'abord Trouver une requête échouée dans CloudWatch Logs et Mesurer la santé d'une application avec les métriques CloudWatch. Ce laboratoire fournit sa propre application et son propre incident.

Lien avec les certifications

Vue d’ensemble du lab

Reproduire l'incident et comparer un témoin

Dans cette étape, vous allez reproduire une requête de commande valide qui échoue de manière inattendue. Le service préparé indépendamment présente un défaut de configuration ordinaire. Ses journaux et métriques sont initialement vides : les observations proviennent donc de vos propres requêtes.

cd /home/labex/project

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-failure-1' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-failure-2' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-control' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/inventory

Attendez-vous à obtenir deux réponses HTTP 503 stock_unavailable de orders et une réponse HTTP 200 accepted de inventory pour la même requête synthétique valide concernant apple. Le témoin suggère un problème propre à orders ; il ne prouve pas que l'ensemble du système est sain.

Utilisez une fenêtre récente en UTC et les dimensions Application exactes pour comparer les nombres d'erreurs serveur. Une métrique résume une fréquence, tandis que des journaux individuels peuvent expliquer une réponse précise.

START=$(date -u -d '15 minutes ago' +%Y-%m-%dT%H:%M:%SZ)
echo "$START"

Enregistrez l’heure de fin de la fenêtre de requête en UTC :

END=$(date -u -d '1 minute' +%Y-%m-%dT%H:%M:%SZ)
echo "$END"

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=inventory \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

Attendez-vous à obtenir un total Sum de 2 pour orders et de 0 pour inventory sur les intervalles renvoyés. Conservez /labex/o05-reference inchangé.

Relier le comptage d'erreurs aux journaux de requêtes

Dans cette étape, vous allez relier le symptôme résumé à des requêtes échouées concrètes. Recherchez d'abord ERROR, puis l'identifiant de requête exact. Une expression entre guillemets correspond au terme request_id complet ; elle évite de mélanger des requêtes aux noms similaires.

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern ERROR \
  --query 'events[].{Time:timestamp,Message:message}'

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern '"request_id=o05-failure-1"' \
  --query 'events[].message'

Les deux échecs indiquent application=orders, le statut 503 et la raison stock_unavailable. Les métriques et journaux couvrent les mêmes requêtes dans la fenêtre récente. Inspectez les paramètres applicatifs pour trouver l'incohérence avec la requête valide concernant apple.

cat app.json

accepted_sku vaut pear pour orders. Inventory utilise indépendamment le paramètre attendu apple. C'est un petit défaut de configuration ; remplacer le service ou désactiver l'observation masquerait le symptôme sans le corriger.

La requête échouée demandait apple, alors que la configuration orders accepte pear. Cet écart fournit une explication vérifiable de stock_unavailable ; la requête inventory réussie aide à délimiter le problème. L’étape suivante teste cette explication en modifiant le réglage orders et en répétant une requête valide. Le rétablissement doit être démontré par une réponse réussie et son nouveau journal correspondant, pas seulement par la modification du fichier.

Corriger le paramètre et vérifier le rétablissement

Dans cette étape, vous allez modifier le SKU accepté et prouver que la réponse métier est rétablie tandis que la télémétrie reste activée. Remplacez la configuration ordinaire par le paramètre corrigé.

cat > app.json <<'JSON'
{"logging": {"enabled": true, "group": "/labex/o05-application", "stream": "requests"}, "metrics": {"enabled": true, "namespace": "LabEx/O05"}, "accepted_sku": "apple"}
JSON

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-recovered' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern '"request_id=o05-recovered"' \
  --query 'events[].message'

Attendez-vous à obtenir HTTP 200 accepted et un journal INFO pour le même identifiant de requête rétablie. Les échecs historiques restent dans la fenêtre. Une requête saine publie Errors=0 : le total cumulé Sum des erreurs reste donc 2, tandis que Requests passe à 3.

START=$(date -u -d '15 minutes ago' +%Y-%m-%dT%H:%M:%SZ)
echo "$START"

Enregistrez l’heure de fin de la fenêtre de requête en UTC :

END=$(date -u -d '1 minute' +%Y-%m-%dT%H:%M:%SZ)
echo "$END"

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Requests \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

AWS View affiche les séries applicatives et les journaux de requêtes réels. Utilisez l'identifiant de la requête rétablie pour distinguer la nouvelle réponse réussie de l'historique des échecs conservé.

Arrêter la télémétrie et nettoyer le groupe de journaux de l'exercice

Dans cette étape, vous allez arrêter l'instrumentation et supprimer uniquement le groupe de journaux de l'incident. Les métriques existantes restent selon la rétention ; il n'existe pas d'API de suppression de métrique individuelle.

cat > app.json <<'JSON'
{"logging": {"enabled": false, "group": "/labex/o05-application", "stream": "requests"}, "metrics": {"enabled": false, "namespace": "LabEx/O05"}, "accepted_sku": "apple"}
JSON

aws logs delete-log-group --log-group-name /labex/o05-application

aws logs describe-log-groups --query 'logGroups[].logGroupName'

aws logs get-log-events \
  --log-group-name /labex/o05-reference \
  --log-stream-name platform \
  --query 'events[].message'

Attendez-vous à obtenir uniquement /labex/o05-reference et son message d'origine INFO platform reference keep unchanged. Un inventaire réussi vérifie la suppression ciblée ; des requêtes échouées n'établiraient pas le nettoyage.

Résumé

Vous avez reproduit un incident avec un témoin, relié les comptages de métriques aux journaux de requêtes, corrigé un paramètre applicatif, vérifié une nouvelle réponse réussie et conservé les preuves historiques jusqu'au nettoyage ciblé.

Pour approfondir ce sujet, consultez la documentation AWS : Identité des métriques, dimensions et statistiques; Filtrage des événements de journal par termes et expressions exactes.