In che modo CloudWatch gli allarmi rilevano gli errori di distribuzione di Amazon ECS

Puoi configurare Amazon ECS in modo che la distribuzione non sia riuscita quando rileva che uno specifico CloudWatch allarme è entrato nello ALARM stato.

Facoltativamente, è possibile impostare la configurazione per ripristinare un'implementazione non riuscita all'ultima implementazione completata.

L'create-service AWS CLI esempio seguente mostra come creare un servizio Linux quando gli allarmi di distribuzione vengono utilizzati con l'opzione rollback.

aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"

Considera quanto segue quando utilizzi il metodo Amazon CloudWatch alarms su un servizio.

• Il tempo di incorporamento è un periodo di tempo dopo che una nuova versione del servizio è stata aumentata e la vecchia versione del servizio è stata ridotta, durante il quale Amazon ECS continua a monitorare l'allarme associato all'implementazione. Amazon ECS calcola questo periodo di tempo in base alla configurazione degli allarmi associata all'implementazione.

• Il parametro della richiesta deploymentConfiguration ora contiene il tipo di dati alarms. È possibile specificare i nomi degli allarmi, se utilizzare il metodo e se avviare un rollback quando gli allarmi indicano un errore di implementazione. Per ulteriori informazioni, consulta il riferimento CreateServiceall'API di Amazon Elastic Container Service.

• La risposta DescribeServices fornisce informazioni sullo stato di un'implementazione, rolloutState e rolloutStateReason. Quando viene avviata una nuova implementazione, lo stato di rollout inizia come IN_PROGRESS. Quando il servizio raggiunge uno stato stazionario ed è stato raggiunto il tempo di incorporamento, lo stato di rollout passa a COMPLETED. Se il servizio non riesce a raggiungere uno stato stazionario e l'allarme è passato allo stato ALARM, l'implementazione passerà a uno stato FAILED. Una implementazione in uno stato FAILED non avvierà nuovi processi.

• Oltre agli eventi di modifica dello stato dell'implementazione del servizio che Amazon ECS invia per le implementazioni che sono state avviate e completate, Amazon ECS invia un evento anche quando un'implementazione che utilizza gli allarmi non riesce. Questi eventi forniscono dettagli sul motivo per cui un'implementazione non è riuscita o se un'implementazione è stata avviata a causa di un ripristino dello stato precedente. Per ulteriori informazioni, consulta Eventi di modifica dello stato di implementazione del servizio Amazon ECS.

• Se una nuova implementazione viene avviata perché un'implementazione precedente non è riuscita ed è stato abilitato il ripristino dello stato precedente, il campo reason dell'evento di modifica dello stato di implementazione del servizio indicherà che l'implementazione è stata avviata a causa di un ripristino dello stato precedente.

• Se utilizzi l'interruttore di distribuzione e gli CloudWatch allarmi Amazon per rilevare i guasti, entrambi possono avviare un errore di distribuzione non appena vengono soddisfatti i criteri per entrambi i metodi. Un rollback si verifica quando si utilizza l'opzione di rollback per il metodo che ha restituito l'errore di implementazione.

• Gli CloudWatch allarmi Amazon sono supportati solo per i servizi Amazon ECS che utilizzano il controller di distribuzione rolling update (ECS).

• Puoi configurare questa opzione utilizzando la console Amazon ECS o il AWS CLI. Per ulteriori informazioni, consulta Creazione di un servizio utilizzando parametri definiti e create-service in Informazioni di riferimento sull'AWS Command Line Interface .

• Potresti notare che lo stato di implementazione rimane IN_PROGRESS per un periodo di tempo prolungato. Questo perché Amazon ECS non modifica lo stato finché non ha eliminato l'implementazione attiva e ciò avviene solo dopo il tempo di incorporamento. A seconda della configurazione degli allarmi, l'implementazione potrebbe richiedere diversi minuti in più rispetto a quando non sono utilizzati gli allarmi (anche se il nuovo set di attività principali è stato aumentato e la vecchia implementazione è stata ridotta). Se utilizzi i CloudFormation timeout, valuta la possibilità di aumentarli. Per ulteriori informazioni, consulta Creazione delle condizioni di attesa in un modello nella Guida per l'utente di AWS CloudFormation .

• Amazon ECS chiama DescribeAlarms per eseguire il polling degli allarmi. Le chiamate verranno DescribeAlarms conteggiate ai fini delle quote di CloudWatch servizio associate al tuo account. Se disponi di altri AWS servizi che effettuano chiamateDescribeAlarms, Amazon ECS potrebbe avere un impatto sulla necessità di interrogare gli allarmi. Ad esempio, se un altro servizio effettua un numero di DescribeAlarms chiamate sufficiente a raggiungere la quota, tale servizio viene limitato e anche Amazon ECS lo è e non è in grado di generare allarmi. Se viene generato un allarme durante il periodo di limitazione, Amazon ECS potrebbe non ricevere l'allarme e il rollback potrebbe non verificarsi. Non ci sono altri impatti sull'implementazione. Per ulteriori informazioni sulle quote di CloudWatch servizio, consulta le quote di CloudWatch servizio nella Guida per l'utente. CloudWatch

• Se all'inizio di una implementazione un allarme si trova nello stato ALARM, Amazon ECS non monitorerà gli allarmi per la durata di tale implementazione (Amazon ECS ignora la configurazione degli allarmi). Questo comportamento risolve il caso in cui si desideri avviare una nuova distribuzione per correggere un errore di distribuzione iniziale.

Allarmi consigliati

È consigliabile utilizzare i seguenti parametri di allarme:

• Se utilizzi un Application Load Balancer, utilizza i parametri HTTPCode_ELB_5XX_Count e HTTPCode_ELB_4XX_Count di Application Load Balancer. Questi parametri controllano i picchi HTTP. Per ulteriori informazioni sulle metriche di Application Load Balancer, consulta CloudWatch le metriche per il tuo Application Load Balancer nella User Guide for Application Load Balancer.

• Per un'applicazione esistente, utilizza i parametri CPUUtilization e MemoryUtilization. Questi parametri controllano la percentuale di CPU e memoria utilizzate dal cluster o dal servizio. Per ulteriori informazioni, consulta Considerazioni.

• Se utilizzi le Amazon Simple Queue Service code nelle tue attività, utilizza la metrica di ApproximateNumberOfMessagesNotVisible Amazon SQS. Questo parametro controlla il numero dei messaggi nella coda che vengono differiti e non sono disponibili per la lettura immediata. Per ulteriori informazioni sui parametri di Amazon SQS, consulta Parametri disponibili per CloudWatch Amazon SQS nella Amazon Simple Queue Service Developer Guide.