Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# CloudWatch Alarme
<a name="cloudwatch-alarms"></a>

Bei dieser Lösung werden zwei CloudWatch Alarme eingesetzt, die die Betriebsbedingungen überwachen, die besondere Aufmerksamkeit erfordern. Standardmäßig sind für diese Alarme keine Benachrichtigungsaktionen konfiguriert. Wir empfehlen, für jeden Alarm ein Amazon SNS SNS-Thema zu abonnieren, damit die Betreiber sofort benachrichtigt werden, wenn Probleme auftreten.

## Abonnieren Sie Alarmbenachrichtigungen
<a name="subscribe-to-alarms"></a>

Um Benachrichtigungen zu erhalten, wenn ein Alarm ausgelöst wird:

1. Öffnen Sie die [CloudWatch Alarm-Konsole](https://console.aws.amazon.com/cloudwatch/home#alarmsV2:).

1. Suchen Sie nach Alarmen, denen Ihr Stack-Name vorangestellt ist (z. B.`my-stack-OrphanCleanupFailure`).

1. Wählen Sie den Alarm aus und wählen Sie **Bearbeiten**.

1. Wählen Sie unter **Benachrichtigung** die Option **Benachrichtigung hinzufügen** aus.

1. Wählen oder erstellen Sie ein SNS-Thema mit Ihren bevorzugten Benachrichtigungsendpunkten (E-Mail, SMS oder Lambda).

1. Wählen Sie **Update Alarm** (Alarm bearbeiten) aus.

Wiederholen Sie den Vorgang für jeden Alarm.

## OrphanCleanupFailure
<a name="orphan-cleanup-failure-alarm"></a>


| Attribut | Wert | 
| --- | --- | 
| Name des Alarms |  `{StackName}-OrphanCleanupFailure`  | 
| Metrik |  `OrphanCleanupFailures`im `distributed-load-testing` Namespace | 
| Threshold | >= 1 Fehler innerhalb von 5 Minuten | 
| Behandeln Sie fehlende Daten | Verstoß | 

 **Was dieser Alarm überwacht:** Die Lösung nutzt drei Schutzebenen, um außer Kontrolle geratene ECS-Services zu verhindern:
+  **Ebene 1: Automatisierte Fehlerbehandlung** — Der Workflow zur Testorchestrierung umfasst die Fehlerbehandlung bei jedem Schritt. Wenn während der Bereitstellung, Stabilisierung oder Ausführung etwas fehlschlägt, löst der Workflow automatisch eine Bereinigung aus, um die ECS-Services zu leeren und zu löschen.
+  **Schicht 2: Erkennung von Ausführungsfehlern** — Wenn der Orchestrierungs-Workflow selbst unerwartet beendet wird (z. B. aufgrund eines Timeouts oder eines internen Fehlers, der die normale Fehlerbehandlung umgeht), erkennt eine EventBridge Regel den Fehler und löst unabhängig eine Bereinigung für jede am Test beteiligte Region aus.
+  **Schicht 3: Stündliche Orphan-Bereinigung** — Ein geplanter Prozess wird jede Stunde ausgeführt, sucht nach ECS-Services, die keinem aktiven Test zugeordnet sind, und erzwingt deren Löschung. Dies ist das letzte Sicherheitsnetz — wenn sowohl Layer 1 als auch Layer 2 ausfallen, werden durchgesickerte Dienste trotzdem innerhalb einer Stunde entfernt. Wenn der Orphan-Bereinigungsprozess selbst fehlschlägt, wird dieser Alarm ausgelöst.

 **Warum das wichtig ist:** Verwaiste ECS Fargate-Dienste werden weiterhin ausgeführt und es fallen Gebühren an, ohne dass sie in der DLT-Konsole angezeigt werden. Ohne ein Benachrichtigungsabonnement werden die Betreiber das Problem erst entdecken, wenn unerwartete Kosten auf der Rechnung erscheinen.

 **Empfohlene Reaktion:** Wenn dieser Alarm ausgelöst wird, navigieren Sie zur [Amazon ECS-Konsole](https://console.aws.amazon.com/ecs/), identifizieren Sie Dienste im DLT-Cluster, die keinem laufenden Test entsprechen, und löschen Sie sie manuell.

## MetricFilterCount
<a name="metric-filter-count-alarm"></a>


| Attribut | Wert | 
| --- | --- | 
| Name des Alarms |  `{StackName}-MetricFilterCount-Alarm`  | 
| Metrik |  `MetricFilterCount`im Namespace `distributed-load-testing` | 
| Threshold | >= 90 | 
| Behandeln Sie fehlende Daten | Kein Verstoß | 

 **Was dieser Alarm überwacht:** Die Lösung erstellt dynamisch CloudWatch Metrikfilter in der ECS-Protokollgruppe, um Live-Metriken während der Testausführung zu unterstützen. AWS begrenzt jede Protokollgruppe auf 100 Metrikfilter. Dieser Alarm wird ausgelöst, wenn die Nutzung 90% dieses Grenzwerts erreicht.

 **Warum das wichtig ist:** Wenn das Limit erreicht wird, schlagen neue Lasttestläufe fehl.

 **Empfohlene Antwort:** Löschen Sie Testszenarien, die nicht mehr benötigt werden. Wenn ein Testszenario gelöscht wird, entfernt die Lösung die zugehörigen Metrikfilter und gibt Kapazität für neue Tests frei.