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

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.

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.

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.



