As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Monitorar implantações para reversão automática
Durante uma implantação, você pode mitigar situações em que dados de configuração malformados ou incorretos causam erros em seu aplicativo usando uma combinação de estratégias de AWS AppConfig implantação e reversões automáticas com base nos alarmes da Amazon. CloudWatch Depois de configurado, se um ou mais CloudWatch alarmes entrarem no INSUFFICIENT_DATA estado ALARM or durante uma implantação, AWS AppConfig reverterá automaticamente seus dados de configuração para a versão anterior, evitando interrupções ou erros no aplicativo.
nota
Uma implantação não é revertida automaticamente se as ações tiverem sido desativadas em um CloudWatch alarme associado.
Você pode desativar e ativar os alarmes usando as ações DisableAlarmActionse EnableAlarmActionsda API ou os enable-alarm-actionscomandos disable-alarm-actionse no AWS CLI.
Você também pode reverter uma configuração chamando a operação da StopDeploymentAPI enquanto a implantação ainda está em andamento.
Importante
Para implantações concluídas com êxito, AWS AppConfig também oferece suporte à reversão dos dados de configuração para uma versão anterior usando o AllowRevert parâmetro com a operação da StopDeploymentAPI. Para alguns clientes, a reversão para uma configuração anterior após uma implantação bem-sucedida garante que os dados sejam os mesmos de antes da implantação. A reversão também ignora os monitores de alarme, o que pode impedir o roll forward durante uma emergência na aplicação. Para obter mais informações, consulte Reverter uma configuração.
Para configurar reversões automáticas, você especifica o Amazon Resource Name (ARN) de uma ou mais CloudWatch métricas no campo de CloudWatch alarmes ao criar (ou editar) um ambiente. AWS AppConfig Para obter mais informações, consulte Criar ambientes para seu aplicativo no AWS AppConfig.
nota
Se você usa uma solução de monitoramento terceirizada (por exemplo, Datadog), você pode criar uma AWS AppConfig extensão que verifica os alarmes no ponto de AT_DEPLOYMENT_TICK ação e, como proteção de segurança, reverte a implantação se ela acionar um alarme. Para obter mais informações sobre AWS AppConfig extensões, consulteEstendendo AWS AppConfig fluxos de trabalho usando extensões. Para obter mais informações sobre extensões personalizadas, consultePasso a passo: Criação de extensões personalizadas AWS AppConfig. Para ver uma amostra de código de uma AWS AppConfig extensão que usa o ponto de AT_DEPLOYMENT_TICK ação para se integrar ao Datadog, consulte aws-samples
Métricas recomendadas para monitorar a reversão automática
As métricas que você escolher monitorar dependerão do hardware e do software usados por seus aplicativos. AWS AppConfig os clientes geralmente monitoram as seguintes métricas. Para obter uma lista completa das métricas recomendadas agrupadas por AWS service (Serviço da AWS), consulte Alarmes recomendados no Guia CloudWatch do usuário da Amazon.
Depois de determinar as métricas que você deseja monitorar, use CloudWatch para configurar alarmes. Para obter mais informações, consulte Usando CloudWatch alarmes da Amazon.
| Serviço | Métrica | Detalhes |
|---|---|---|
|
4 XXError |
Esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar um problema na autorização ou nos parâmetros da solicitação do cliente. Isso também pode significar que um recurso foi removido ou que um cliente está solicitando um recurso que não existe. Considere ativar o Amazon CloudWatch Logs e verificar se há erros que possam estar causando os erros 4XX. Além disso, considere ativar CloudWatch métricas detalhadas para visualizar essa métrica por recurso e método e restringir a origem dos erros. Os erros também podem ser causados por exceder o limite de controle de utilização configurado. |
|
|
5XXError |
Esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar que há algo errado no backend da API, na rede ou na integração entre o gateway da API e a API de backend. |
|
|
Latência |
Esse alarme detecta alta latência em um estágio. Encontre o valor da métrica |
|
|
GroupInServiceCapacity |
Esse alarme ajuda a detectar quando a capacidade do grupo está abaixo da capacidade desejada para a workload. Para solucionar problemas, verifique se há falhas de inicialização em suas atividades de escalonamento e confirme se a configuração da capacidade desejada está correta. |
|
|
CPUUtilization |
Esse alarme ajuda a monitorar a utilização da CPU de uma EC2 instância. Dependendo da aplicação, níveis de utilização consistentemente altos podem ser normais. Porém, se a performance for prejudicada e a aplicação não for limitada por E/S de disco, memória ou recursos de rede, uma CPU no limite máximo poderá indicar um gargalo de recursos ou problemas de performance da aplicação. |
|
|
CPUReservation |
Esse alarme ajuda a detectar uma alta reserva de CPU no cluster do ECS. A alta reserva de CPU pode indicar que o cluster está ficando sem registros CPUs para a tarefa. |
|
|
HTTPCode_TARGET_5xx_count |
Esse alarme ajuda você a detectar uma alta contagem de erros do lado do servidor para o serviço ECS. Isso pode indicar que há erros que fazem com que o servidor não consiga atender às solicitações. |
|
|
node_cpu_utilization |
Esse alarme ajuda a detectar a alta utilização da CPU nos nós de processamento do cluster do Amazon EKS. Se a utilização for consistentemente alta, isso pode indicar a necessidade de substituir os nós de processamento por instâncias que tenham mais CPU ou a necessidade de escalar o sistema horizontalmente. |
|
|
node_memory_utilization |
Esse alarme ajuda a detectar a alta utilização de memória nos nós de processamento do cluster do Amazon EKS. Se a utilização for consistentemente alta, isso pode indicar a necessidade de escalar o número de réplicas de pod ou otimizar a sua aplicação. |
|
|
pod_cpu_utilization_over_pod_limit |
Esse alarme ajuda a detectar a alta utilização da CPU em pods do cluster do Amazon EKS. Se a utilização for consistentemente alta, isso poderá indicar a necessidade de aumentar o limite da CPU para o pod afetado. |
|
|
pod_memory_utilization_over_pod_limit |
Esse alarme ajuda a detectar a alta utilização da CPU em pods do cluster do Amazon EKS. Se a utilização for consistentemente alta, isso poderá indicar a necessidade de aumentar o limite da CPU para o pod afetado. |
|
|
Erros |
Esse alarme detecta altas contagens de erros. Os erros incluem as exceções lançadas pelo código, bem como as exceções lançadas pelo runtime do Lambda. |
|
|
Controles de utilização |
Esse alarme detecta um alto número de solicitações de invocação com controle de utilização. O controle de utilização ocorre quando não há simultaneidade disponível para aumentar a escala verticalmente. |
|
|
memory_utilization |
Esse alarme é usado para detectar se a utilização da memória de uma função do Lambda está se aproximando do limite configurado. |
|
|
4xxErrors |
Esse alarme nos ajuda a informar o número total de códigos de status de erro 4xx que são gerados em resposta a solicitações de clientes. Os códigos de erro 403 podem indicar uma política do IAM incorreta e os códigos de erro 404 podem indicar uma aplicação cliente com comportamento incorreto, por exemplo. |
|
|
5xxErrors |
Esse alarme ajuda a detectar um grande número de erros do lado do servidor. Esses erros indicam que um cliente fez uma solicitação que o servidor não conseguiu concluir. Isso pode ajudar você a correlacionar o problema que sua aplicação está enfrentando por causa do S3. |
