Einen Vorfall mit Logs und Metriken diagnostizieren

Einführung

Gültige Bestellungen schlagen fehl, während eine Bestandsanfrage erfolgreich ist. Du vergleichst Anwendungsmetriken, verfolgst eine fehlgeschlagene Anfrage in Logs, reparierst einen kleinen Konfigurationsfehler und bestätigst die Erholung, ohne den Fehlerverlauf zu löschen.

Schließe zuerst Eine fehlgeschlagene Anfrage in CloudWatch Logs finden und Den Anwendungszustand mit CloudWatch-Metriken messen ab. Dieses Lab stellt eine eigene Anwendung und einen eigenen Vorfall bereit.

Bezug zu Zertifizierungen

Lab-Überblick

Den Vorfall reproduzieren und einen Kontrollfall vergleichen

In diesem Schritt reproduzierst du eine gültige Bestellanfrage, die unerwartet fehlschlägt. Der unabhängig vorbereitete Dienst hat einen gewöhnlichen Konfigurationsfehler. Seine Logs und Metriken sind anfangs leer, sodass die Beobachtungen aus deinen eigenen Anfragen stammen.

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

Erwarte für dieselbe gültige synthetische apple-Anfrage zwei Antworten mit HTTP 503 stock_unavailable von orders und eine Antwort mit HTTP 200 accepted von inventory. Der Kontrollfall deutet auf ein orders-spezifisches Problem hin; er belegt nicht, dass das gesamte System fehlerfrei ist.

Verwende ein aktuelles UTC-Zeitfenster und genaue Application-Dimensionen, um Serverfehleranzahlen zu vergleichen. Eine Metrik fasst die Häufigkeit zusammen, während einzelne Logs eine bestimmte Antwort erklären können.

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

Speichere die Endzeit des Abfragefensters in 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

Erwarte über die zurückgegebenen Intervalle hinweg für orders Sum 2 und für inventory Sum 0. Lasse /labex/o05-reference unverändert.

Die Fehleranzahl mit Anfrage-Logs verbinden

In diesem Schritt verbindest du das zusammengefasste Symptom mit konkreten fehlgeschlagenen Anfragen. Frage zuerst ERROR und anschließend die genaue Anfrage-ID ab. Eine Phrase in Anführungszeichen stimmt mit dem vollständigen request_id-Token überein; so vermischst du keine ähnlich benannten Anfragen.

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'

Beide Fehler nennen application=orders, Status 503 und den Grund stock_unavailable. Die Metriken und Logs erfassen dieselben Anfragen im aktuellen Zeitfenster. Prüfe die Anwendungseinstellungen, um die Abweichung von der gültigen apple-Anfrage zu finden.

cat app.json

accepted_sku ist für orders auf pear gesetzt. Inventory verwendet unabhängig davon die erwartete apple-Einstellung. Dies ist ein kleiner Konfigurationsfehler; den Dienst zu ersetzen oder die Beobachtung zu deaktivieren würde das Symptom verbergen, ohne es zu beheben.

Die fehlgeschlagene Anfrage enthielt apple, während die orders-Konfiguration pear akzeptiert. Diese Abweichung ist eine überprüfbare Erklärung für stock_unavailable; die erfolgreiche inventory-Anfrage grenzt den Fehler ein. Im nächsten Schritt prüfst du diese Erklärung, indem du die orders-Einstellung änderst und eine gültige Anfrage wiederholst. Eine erfolgreiche Antwort und ihr neuer zugehöriger Log-Eintrag belegen die Wiederherstellung, nicht die Konfigurationsänderung allein.

Die Einstellung reparieren und die Erholung prüfen

In diesem Schritt änderst du die akzeptierte SKU und weist nach, dass die fachliche Antwort wieder erfolgreich ist, während die Telemetrie aktiviert bleibt. Ersetze die gewöhnliche Konfiguration durch die korrigierte Einstellung.

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'

Erwarte HTTP 200 accepted und ein INFO-Log für dieselbe Anfrage-ID der wiederhergestellten Funktion. Frühere Fehler bleiben im Zeitfenster enthalten. Eine fehlerfreie Anfrage veröffentlicht Errors=0, sodass die kumulierte Fehlersumme bei 2 bleibt, während Requests auf 3 steigt.

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

Speichere die Endzeit des Abfragefensters in 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 zeigt tatsächliche Anwendungsreihen und Anfrage-Logs. Verwende die Anfrage-ID der wiederhergestellten Funktion, um die neue erfolgreiche Antwort vom erhaltenen Fehlerverlauf zu unterscheiden.

Telemetrie stoppen und die eigene Log-Gruppe bereinigen

In diesem Schritt stoppst du die Instrumentierung und entfernst ausschließlich die Log-Gruppe des Vorfalls. Bestehende Metriken bleiben entsprechend ihrer Aufbewahrung erhalten; es gibt keine API zum Löschen einer einzelnen Metrik.

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'

Erwarte nur /labex/o05-reference und ihre ursprüngliche Nachricht INFO platform reference keep unchanged. Ein erfolgreicher Bestandsabruf bestätigt die gezielte Löschung; fehlgeschlagene Abfragen würden die Bereinigung nicht belegen.

Zusammenfassung

Du hast einen Vorfall mit einem Kontrollfall reproduziert, Metrikanzahlen mit Anfrage-Logs verbunden, eine Anwendungseinstellung repariert, eine neue erfolgreiche Antwort geprüft und historische Nachweise bis zur gezielten Bereinigung erhalten.

Weitere Informationen bietet die AWS-Dokumentation: Metrikidentität, Dimensionen und Statistiken; Logereignisse nach Begriffen und exakten Phrasen filtern.