In che modo gli allarmi CloudWatch rilevano gli errori di implementazione di Amazon ECS
È possibile configurare Amazon ECS in modo che imposti l'implementazione come non riuscita quando rileva che un allarme CloudWatch specificato è passato allo stato ALARM.
Facoltativamente, è possibile impostare la configurazione per ripristinare un'implementazione non riuscita all'ultima implementazione completata.
Il seguente esempio create-service AWS CLI mostra come creare un servizio Linux quando gli allarmi di implementazione sono utilizzati con l'opzione di rollback.
aws ecs create-service \ --service-nameMyService\ --deployment-controller type=ECS\ --desired-count3\ --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \ --task-definitionsample-fargate:1\ --launch-typeFARGATE\ --platform-familyLINUX\ --platform-version1.4.0\ --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
Le seguenti considerazioni si applicano quando si utilizza il metodo degli allarmi Amazon CloudWatch in un servizio.
-
La durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione. Amazon ECS calcola questo periodo di tempo in base alla configurazione degli allarmi associata all'implementazione. Non è possibile impostare questo valore.
-
Il parametro della richiesta
deploymentConfigurationora contiene il tipo di datialarms. È 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, consultare CreateService nella Documentazione di riferimento delle API di Amazon Elastic Container Service. -
La risposta
DescribeServicesfornisce informazioni sullo stato di un'implementazione,rolloutStateerolloutStateReason. Quando viene avviata una nuova implementazione, lo stato di rollout inizia comeIN_PROGRESS. Quando il servizio raggiunge uno stato stazionario ed è stato raggiunto il tempo di incorporamento, lo stato di rollout passa aCOMPLETED. Se il servizio non riesce a raggiungere uno stato stazionario e l'allarme è passato allo statoALARM, l'implementazione passerà a uno statoFAILED. Una implementazione in uno statoFAILEDnon 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, consultare 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
reasondell'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 implementazione e gli allarmi di Amazon CloudWatch per rilevare gli errori, entrambi possono restituire un errore di implementazione 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 allarmi Amazon CloudWatch sono supportati solo per i servizi Amazon ECS che utilizzano il controller di implementazione (
ECS) dell'aggiornamento in sequenza. -
È possibile configurare questa opzione utilizzando la console di Amazon ECS o la AWS CLI. Per ulteriori informazioni, consultare 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_PROGRESSper 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 timeout di CloudFormation, valuta la possibilità di aumentarli. Per ulteriori informazioni, consultare Creating wait conditions in a template nella Guida per l'utente di AWS CloudFormation. -
Amazon ECS chiama
DescribeAlarmsper eseguire il polling degli allarmi. Le chiamate aDescribeAlarmsvengono conteggiate ai fini delle quote del servizio CloudWatch associate all'account. Se hai altri servizi AWS che effettuano chiamate aDescribeAlarms, il polling degli allarmi da parte di Amazon ECS potrebbe risentirne. Ad esempio, se un altro servizio effettua un numero sufficiente di chiamate aDescribeAlarmsper raggiungere la quota, tale servizio viene limitato e Amazon ECS non sarà in grado di eseguire il polling degli allarmi. Se viene generato un allarme durante il periodo di limitazione, Amazon ECS potrebbe non rilevare l'allarme e il rollback potrebbe non verificarsi. Non ci sono altri impatti sull'implementazione. Per maggiori informazioni sulle quote di servizio di CloudWatch, consulta Service Quotas di CloudWatch nella Guida per l'utente di 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 implementazione per correggere un errore di implementazione iniziale.
Allarmi consigliati
È consigliabile utilizzare i seguenti parametri di allarme:
-
Se utilizzi un Application Load Balancer, utilizza i parametri
HTTPCode_ELB_5XX_CounteHTTPCode_ELB_4XX_Countdi Application Load Balancer. Questi parametri controllano i picchi HTTP. Per ulteriori informazioni, consulta sui parametri di Application Load Balancer, consulta Parametri CloudWatch per Application Load Balancer nella Guida per l'utente di Application Load Balancer. -
Per un'applicazione esistente, utilizza i parametri
CPUUtilizationeMemoryUtilization. Questi parametri controllano la percentuale di CPU e memoria utilizzate dal cluster o dal servizio. Per ulteriori informazioni, consultare Considerazioni. -
Se nelle tue attività utilizzi le code Amazon Simple Queue Service, utilizza il parametro
ApproximateNumberOfMessagesNotVisibledi 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, consulta Parametri CloudWatch disponibili per Amazon SQS nella Guida per sviluppatori di Amazon Simple Queue Service.
Tempo di incorporamento
Quando si utilizza l'opzione di rollback per le implementazioni dei servizi, Amazon ECS attende un ulteriore periodo di tempo dopo l'implementazione della revisione del servizio di destinazione prima di inviare un allarme CloudWatch. Questo è indicato come tempo di incorporamento, che inizia dopo che:
-
Tutte le attività per una revisione del servizio di destinazione sono in esecuzione e in buono stato
-
Le revisioni del servizio di origine vengono ridotte allo 0%
Il tempo di incorporamento predefinito è inferiore a 5 minuti. L'implementazione del servizio viene contrassegnata come completa dopo la scadenza del tempo di incorporamento.
È possibile configurare il tempo di incorporamento per un'implementazione continua. Quando si utilizzano gli allarmi CloudWatch per rilevare un errore, se si modifica il tempo di incorporamento e poi si decide di utilizzare l'impostazione predefinita di Amazon ECS, è necessario impostare manualmente il tempo di incorporamento.