Erkenne Website-Fehler und bestätige die Wiederherstellung

AWSBeginner
Jetzt üben

Einführung

Erstelle einen Anfragealarm, veröffentliche ein ungültiges Profil und stelle Website sowie OK-Zustand wieder her.

Schließe die vorherigen Portfolio-Labs ab. Dieses Lab liefert eigene Ressourcen und benötigte frühere Fähigkeiten. Übernimm Wissen, keine alten Instanzen, Dateien oder Zugangsdaten.

Zertifizierungsbezug

Zertifizierung Aufgaben Übung
AWS Certified Cloud Practitioner (CLF-C02) Task 3.8 Fehler und Wiederherstellung mit Metriken, Alarmen und Logs beobachten.

Überblick

Erstelle einen Anfragealarm, veröffentliche ein ungültiges Profil und stelle Website sowie OK-Zustand wieder her.

Fehleralarm konfigurieren

In diesem Schritt beobachtest du tatsächliche Anfragen. Öffne zuerst die gesunde Seite. Eine Metrik ist ein zeitlicher Messwert, Namespace gruppiert und Dimension identifiziert die Anwendung. Errors in LabEx/Portfolio, Application=portfolio, misst 1 bei Fehler, 0 bei Erfolg. Ein Alarm vergleicht mit einem Schwellwert, repariert aber nicht. Errors misst hier nur Seitenanfragen an /website. Bilder und andere Dateien erzeugen separate Logereignisse.

Wechsle zum Projekt.

cd /home/labex/project

Lade und zeige die Instanz.

source website.env
echo "$INSTANCE_ID"

Lies Sum, Period=10, EvaluationPeriods=1 und GreaterThanThreshold bei Schwelle 0. missing setzt fehlende Daten nicht mit gesunden Anfragen gleich. Die vorbereitete Integration liefert hochauflösende eigene Metriken pro Sekunde; keine Benachrichtigungen sind eingerichtet.

cat website-alarm.json

Erstelle den Alarm aus der Datei.

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

Lies den Zustand.

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

INSUFFICIENT_DATA kann anfänglich fehlende ausgewertete Daten bedeuten. AWS View zeigt denselben Wert. Setze ihn nicht manuell.

Eine fehlerhafte Veröffentlichung beobachten

In diesem Schritt veröffentlichst du absichtlich ungültiges JSON ohne Netzwerk- oder Berechtigungsänderung.

Lies das vorbereitete defekte Profil.

cat profile-broken.json

Übertrage es mit SCP auf denselben Profilpfad.

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

Lade die Seite neu: Website unavailable, EC2 bleibt running. Finde path=/website status=503 und verbinde den Fehler mit deiner jüngsten Veröffentlichung. Das Muster ist eine genaue Phrase: äußere einfache Anführungszeichen erhalten die inneren doppelten Anführungszeichen.

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

Warte eine Zehn-Sekunden-Periode, erzeuge bei Bedarf weitere fehlgeschlagene Anfragen und lies den Alarm.

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

Bestätige ALARM. Bei fehlenden Daten erneut echte Anfragen erzeugen und die Auswertung abwarten. Ein alter Log ist kein aktueller Messpunkt.

Realer Prüfpunkt des Labs; deine Ressourcenkennungen können abweichen.

Website reparieren und prüfen

In diesem Schritt stellst du das gültige Profil wieder her und prüfst Anwendung und Alarm.

Lies die drei gültigen Felder der bekannten Datei.

cat profile-working.json

Übertrage sie zum gleichen Ziel.

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

Lade für Alex Morgan und das S3-Bild neu und finde ein neues path=/website status=200. Das Muster ist eine genaue Phrase: äußere einfache Anführungszeichen erhalten die inneren doppelten Anführungszeichen.

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

Lass gesunden Verkehr eine neue Periode durchlaufen; aktualisiere bei Bedarf und prüfe den Alarm.

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

Bestätige OK. Alte 503 bleiben in der Historie. Ohne Anfragen kann missing zu INSUFFICIENT_DATA führen, was kein nachgewiesener gesunder Verkehr ist. Halte Erfolge bei der Prüfung aktuell.

Realer Prüfpunkt des Labs; deine Ressourcenkennungen können abweichen.

Workload und Überwachung entfernen

In diesem Schritt bereinigst du nach bestätigter Wiederherstellung.

Beende die Instanz.

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

Warte auf terminated.

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

Entferne ausschließlich portfolio-errors.

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

Lösche die Log Group des Labs.

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

Bewahre S3, Rolle, Netzwerk und Referenzlogs. Ein gelöschter Alarm löscht keine Metriken; ein beendeter Workload sendet keine neuen Website-Messpunkte. Fahre mit AWS Resource Management for Beginners fort.

Zusammenfassung

Du hast 503 und ALARM beobachtet, das Profil repariert und 200 sowie OK bestätigt, dann gezielt bereinigt.

Offizielle Quellen: CloudWatch alarms, high-resolution custom metrics.