Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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

Questa soluzione implementa due CloudWatch allarmi che monitorano le condizioni operative che richiedono attenzione. Per impostazione predefinita, per questi allarmi non sono configurate azioni di notifica. Consigliamo di sottoscrivere un argomento Amazon SNS per ogni allarme in modo che gli operatori ricevano una notifica immediata in caso di problemi.

## Iscriviti alle notifiche di allarme
<a name="subscribe-to-alarms"></a>

Per ricevere notifiche quando viene attivato un allarme:

1. Apri la console [CloudWatch Allarmi](https://console.aws.amazon.com/cloudwatch/home#alarmsV2:).

1. Cerca gli allarmi con il prefisso del nome dello stack (ad esempio,). `my-stack-OrphanCleanupFailure`

1. **Seleziona l'allarme e scegli Modifica.**

1. In **Notifica**, scegli **Aggiungi notifica**.

1. Seleziona o crea un argomento SNS con i tuoi endpoint di notifica preferiti (e-mail, SMS o Lambda).

1. Seleziona **Update Alarm (Aggiorna allarme)**.

Ripetere l'operazione per ogni allarme.

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


| Attributo | Valore | 
| --- | --- | 
| Nome allarme |  `{StackName}-OrphanCleanupFailure`  | 
| Metrica |  `OrphanCleanupFailures`nel `distributed-load-testing` namespace | 
| Threshold | >= 1 errore entro 5 minuti | 
| Tratta i dati mancanti | Violazione | 

 **Cosa monitora questo allarme:** la soluzione utilizza tre livelli di difesa per prevenire l'inattività dei servizi ECS:
+  **Livello 1: gestione automatizzata degli errori** — Il flusso di lavoro di orchestrazione dei test include la gestione degli errori in ogni fase. Se qualcosa non funziona durante il provisioning, la stabilizzazione o l'esecuzione, il flusso di lavoro attiva automaticamente la pulizia per svuotare ed eliminare i servizi ECS.
+  **Livello 2: rilevamento degli errori di esecuzione:** se il flusso di lavoro di orchestrazione stesso si chiude in modo imprevisto (ad esempio, a causa di un timeout o di un errore interno che aggira la normale gestione degli errori), una EventBridge regola rileva l'errore e avvia la pulizia in modo indipendente per ogni area coinvolta nel test.
+  **Livello 3: pulizia oraria** degli orfani: un processo pianificato viene eseguito ogni ora, esegue la scansione dei servizi ECS non associati a nessun test attivo e li elimina forzatamente. Questa è la rete di sicurezza di ultima istanza: se sia il livello 1 che il livello 2 falliscono, i servizi compromessi vengono comunque rimossi entro un'ora. Se lo stesso processo di pulizia degli orfani fallisce, viene attivato questo allarme.

 **Perché è importante:** i servizi ECS Fargate orfani continuano a funzionare e incorrono in costi senza visibilità nella console DLT. Senza un abbonamento alle notifiche, gli operatori scopriranno il problema solo quando sulla bolletta compaiono costi imprevisti.

 **Risposta consigliata:** quando si attiva questo allarme, accedi alla [console Amazon ECS](https://console.aws.amazon.com/ecs/), identifica i servizi nel cluster DLT che non corrispondono a un test in esecuzione ed eliminali manualmente.

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


| Attributo | Valore | 
| --- | --- | 
| Nome allarme |  `{StackName}-MetricFilterCount-Alarm`  | 
| Metrica |  `MetricFilterCount`nel namespace `distributed-load-testing` | 
| Threshold | >= 90 | 
| Tratta i dati mancanti | Non violare | 

 **Cosa monitora questo allarme:** la soluzione crea filtri CloudWatch metrici in modo dinamico sul gruppo di log ECS per supportare le metriche in tempo reale durante l'esecuzione del test. AWS limita ogni gruppo di log a 100 filtri metrici. Questo allarme si attiva quando l'utilizzo raggiunge il 90% di tale limite.

 **Perché è importante:** se il limite viene raggiunto, i nuovi test di carico falliranno.

 **Risposta consigliata:** elimina gli scenari di test che non sono più necessari. Quando uno scenario di test viene eliminato, la soluzione rimuove i filtri metrici associati e libera capacità per nuovi test.