In che modo CloudWatch gli allarmi rilevano gli errori di ECS distribuzione di Amazon - Amazon Elastic Container Service
Allarmi consigliati

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à.

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

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 attesa è un periodo di tempo dopo la scalabilità orizzontale di una nuova versione del servizio e quella precedente, 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 alla distribuzione.

  • 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 CreateServiceAmazon Elastic Container Service API Reference.

  • 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 di distribuzione del servizio che Amazon ECS invia per le distribuzioni iniziate e completate, Amazon invia ECS anche un evento quando una distribuzione che utilizza allarmi fallisce. 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 ECS servizio Amazon.

  • 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 ECS i servizi Amazon che utilizzano il controller di distribuzione rolling update (ECS).

  • Puoi configurare questa opzione utilizzando la ECS console Amazon 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. Il motivo è che Amazon ECS non modifica lo stato finché non elimina la distribuzione attiva, e ciò accade solo dopo il tempo di cottura. 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 sondare gli allarmi. Le chiamate vengono DescribeAlarms conteggiate ai fini delle quote CloudWatch di servizio associate al tuo account. Se disponi di altri AWS servizi che effettuano chiamateDescribeAlarms, Amazon potrebbe avere un impatto sulla necessità ECS 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 lo è e non ECS è in grado di eseguire sondaggi sugli allarmi. Se viene generato un allarme durante il periodo di limitazione, Amazon ECS potrebbe non sentire 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 un allarme è attivo all'ALARMinizio di una distribuzione, Amazon non ECS monitorerà gli allarmi per tutta la durata della distribuzione (Amazon ECS ignora la configurazione degli allarmi). Questo comportamento risolve il caso in cui 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. Queste metriche verificano la presenza di HTTP picchi. 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. Queste metriche controllano la percentuale di memoria utilizzata dal cluster o dal CPU servizio. Per ulteriori informazioni, consulta Considerazioni.

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