Monitorar implantações para reversão automática
Durante uma implantação, é possível atenuar situações em que a implantação de dados de configuração incorretos ou malformados causa erros na aplicação usando uma combinação de estratégias de implantação do AWS AppConfig e reversões automáticas com base nos alarmes do Amazon CloudWatch. Depois de configurado, se um ou mais alarmes do CloudWatch entrarem no estado de ALARM durante uma implantação, o AWS AppConfig reverterá automaticamente os dados de configuração para a versão anterior, evitando, dessa forma, interrupções ou erros na aplicação. Também é possível reverter uma configuração chamando a operação de API StopDeployment enquanto a implantação ainda está em andamento.
Importante
Em implantações concluídas com êxito, o AWS AppConfig também permite a reversão dos dados de configuração para uma versão anterior usando o parâmetro AllowRevert com a operação de API StopDeployment. 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 ter mais informações, consulte Reverter uma configuração.
Para configurar reversões automáticas, você especifica o nome do recurso da Amazon (ARN) de uma ou mais métricas do CloudWatch no campo Alarmes do CloudWatch ao criar (ou editar) um ambiente do AWS AppConfig. Para ter mais informações, consulte Criar ambientes para seu aplicativo no AWS AppConfig.
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 suas aplicações. Os clientes do AWS AppConfig geralmente monitoram as métricas a seguir. Para ter uma lista completa das métricas recomendadas agrupadas por AWS service (Serviço da AWS), consulte Alarmes recomendados no Guia do usuário do Amazon CloudWatch.
Depois de determinar as métricas que você deseja monitorar, use o CloudWatch para configurar alarmes. Para obter mais informações, consulte Uso de alarmes do Amazon CloudWatch.
| Serviço | Métrica | Detalhes |
|---|---|---|
|
4XXError |
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. Pense na possibilidade de habilitar o Amazon CloudWatch Logs e conferir se há alguma falha que possa estar causando os erros 4XX. Ademais, considere a possibilidade de ativar as métricas detalhadas do CloudWatch 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 instância do EC2. 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 CPUs registradas 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. |
