Alarmes e alarmes compostos do CloudWatch

Um alarme do CloudWatch monitora uma única métrica ou o resultado de uma expressão de matemática de métricas durante um período que você especifica. Quando a métrica ultrapassa um limite definido por você, o alarme muda de estado e pode acionar uma ação automaticamente, como enviar uma notificação do SNS, ajustar um grupo de Auto Scaling, interromper uma instância do EC2 ou executar um OpsItem do Systems Manager. Os alarmes são o principal mecanismo de resposta operacional automatizada na AWS.

Um alarme do CloudWatch está sempre em um de três estados: OK — a métrica está dentro do limite definido; ALARM — a métrica ultrapassou o limite durante o número necessário de períodos de avaliação; DADOS_INSUFICIENTES — o alarme acabou de ser criado, a métrica não está disponível ou ainda não foram coletados dados suficientes. As transições entre estados acionam as ações configuradas para essa mudança de estado — você pode ter tópicos do SNS diferentes para os estados OK, ALARM e DADOS_INSUFICIENTES.

Ao criar um alarme, você especifica: a métrica e o namespace, a estatística (Average, Sum, Maximum etc.), o período (com que frequência a métrica é avaliada, em segundos), os períodos de avaliação (quantos períodos consecutivos precisam ultrapassar o limite), o valor do limite e o operador de comparação. O alarme é acionado quando a métrica ultrapassa o limite durante o número especificado de períodos consecutivos de avaliação.

As ações de alarme podem ter vários destinos: tópicos do Amazon SNS (para enviar e-mails, SMS ou acionar o Lambda), políticas de Auto Scaling (para reduzir ou aumentar um ASG) e ações do EC2 (para interromper, encerrar, reinicializar ou recuperar uma instância do EC2). Para cada estado (OK, ALARM, DADOS_INSUFICIENTES), você pode especificar um conjunto diferente de ações — por exemplo, notificar a equipe no estado ALARM, enviar uma notificação de recuperação no estado OK e alertar no estado DADOS_INSUFICIENTES para identificar falhas de monitoramento.

Quando o CloudWatch avalia um alarme e alguns pontos de dados estão ausentes, você precisa decidir como tratá-los. As opções são: notBreaching (considerar os dados ausentes como estando dentro do limite — o alarme permanece em OK se os outros dados estiverem OK), breaching (considerar os dados ausentes como acima do limite — o alarme passa para ALARM), ignore (o estado do alarme não muda) e missing (o alarme passa para DADOS_INSUFICIENTES). Escolher a opção errada causa falsos positivos ou falhas silenciosas — uma particularidade importante do exame SAA-C03.

A resolução do alarme é o produto de período × períodos de avaliação. Por exemplo, um período de 60 segundos com 5 períodos de avaliação significa que o alarme considera 5 pontos de dados consecutivos de 1 minuto. Por padrão, o alarme só passa para ALARM quando todos os cinco períodos ultrapassam o limite. Você pode configurar datapoints-to-alarm para exigir que apenas M de N períodos ultrapassem o limite — por exemplo, 3 de 5 — reduzindo os falsos positivos causados por picos temporários.

Um alarme composto avalia o estado de vários outros alarmes usando lógica booleana (AND, OR, NOT). Ele entra no estado ALARM somente quando sua expressão de regra é avaliada como verdadeira. Os alarmes compostos são usados para reduzir o excesso de alertas — por exemplo, alertar somente se os alarmes de CPU alta E latência alta estiverem sendo acionados simultaneamente, pois uma CPU alta isoladamente pode ser aceitável durante o processamento em lote. Você também pode usar alarmes compostos para suprimir alarmes filhos durante janelas de manutenção.

Os alarmes compostos são compatíveis com ações de supressão de alarmes — você pode configurar um alarme composto para suprimir seus alarmes filhos durante uma manutenção planejada. Por exemplo, durante uma janela de implantação, você pode configurar um alarme composto que combine um alarme 'MaintenanceMode' com a lógica OR, suprimindo todas as notificações dos alarmes filhos enquanto a manutenção estiver ativa. Isso evita uma avalanche de alertas quando você coloca serviços intencionalmente offline para realizar atualizações.

Os grupos de Auto Scaling usam alarmes do CloudWatch como gatilhos para políticas de escalabilidade por etapas e de escalabilidade simples. Quando o alarme entra no estado ALARM, a política de escalabilidade é executada. Na escalabilidade por etapas, você define vários ajustes de escalabilidade para diferentes faixas de limite — por exemplo, adicionar 1 instância se a CPU estiver entre 70% e 80%, adicionar 3 se estiver entre 80% e 90% e adicionar 5 se estiver acima de 90%. O alarme aciona a primeira etapa aplicável com base no nível da violação no momento da avaliação.

Você pode criar alarmes de cobrança no CloudWatch para receber notificações quando os custos estimados da AWS ultrapassarem um limite. As métricas de cobrança são publicadas somente na região us-east-1, independentemente de onde seus recursos estejam em execução, e são atualizadas aproximadamente a cada 6 horas. Para habilitar os alarmes de cobrança, primeiro você precisa ativar os Billing Alerts no console de faturamento da AWS. A ferramenta mais precisa é o AWS Budgets, mas os alarmes de cobrança do CloudWatch continuam sendo uma opção válida cobrada no exame.

Você pode definir manualmente o estado de um alarme usando o comando set-alarm-state para testar as ações do alarme sem esperar uma violação real do limite. Isso é útil para verificar se seus tópicos do SNS, políticas de Auto Scaling e funções do Lambda respondem corretamente. Sempre teste as ações dos alarmes em um ambiente que não seja de produção e confirme que as assinaturas de e-mail corretas do tópico do SNS foram confirmadas antes de depender dos alarmes para alertas de produção.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: os alarmes têm três estados (OK, ALARM, DADOS_INSUFICIENTES) e podem acionar ações do SNS, Auto Scaling e EC2; datapoints-to-alarm permite a avaliação M-de-N para reduzir falsos positivos; e os alarmes compostos usam lógica booleana para combinar vários alarmes e suprimir o excesso de alertas. Em seguida, exploraremos o CloudWatch Logs e o Log Insights para o gerenciamento centralizado de registros.