AWS•Preparação para certificação

Amazon CloudWatch

Guia completo de CloudWatch: métricas padrão vs CloudWatch Agent, estados de alarme, monitoramento standard vs detalhado, log groups/streams, subscription filters, Synthetics e Contributor Insights — para a certificação AWS Solutions Architect Associate.

AWS Certified Solutions Architect – Associate•Intermediário•20 minutos

Amazon CloudWatch coleta métricas, logs e eventos; permite criar alarms e dashboards para monitoramento e resposta.

🎯 Para a certificação

Questões avaliam como usar métricas customizadas, o CloudWatch Agent (e o que ele adiciona que não existe por padrão), estados de alarme, dashboards, e quando usar CloudWatch Logs Insights, EventBridge e Synthetics para observabilidade e automação.

Resumo

Pense no CloudWatch como o painel de instrumentos de um carro. Velocidade, RPM e temperatura do motor já vêm prontos de fábrica (métricas padrão de EC2/RDS/ELB) — mas se você quiser medir algo específico do seu carro (ex: pressão de um pneu específico), precisa instalar um sensor extra. É basicamente isso que separa métricas padrão de métricas customizadas via CloudWatch Agent: nem tudo que parece "óbvio" de se medir já vem coletado automaticamente.

  • Métricas: séries temporais numéricas — padrão (coletadas automaticamente por muitos serviços) ou custom (enviadas pela sua aplicação ou pelo CloudWatch Agent).
  • Logs: texto estruturado ou não, organizado em log groups e log streams, consultável via Logs Insights.
  • Alarms: observam uma métrica e mudam de estado (e disparam ações) quando um limite é ultrapassado.
  • Dashboards: painéis visuais combinando métricas de múltiplas fontes.
  • EventBridge: reage a eventos discretos (não métricas contínuas) e aciona automações.

1. A pegadinha mais comum: o que o EC2 reporta sem agente nenhum

Por padrão, sem instalar nada, uma instância EC2 já envia ao CloudWatch métricas vindas do hypervisor — coisas que a AWS consegue medir de fora da instância: CPUUtilization, NetworkIn/NetworkOut, DiskReadOps/DiskWriteOps (contagem de operações, não uso de espaço), e status checks.

O que a AWS não consegue medir de fora, e por isso não existe por padrão: uso de memória RAM, uso de espaço em disco (percentual ocupado), processos rodando, ou qualquer métrica que exija olhar dentro do sistema operacional. Para essas, é obrigatório instalar o CloudWatch Agent dentro da instância — ele roda como um processo no SO e envia essas métricas adicionais (namespace customizado, geralmente CWAgent).

💡 Regra para a prova: se o cenário descreve "não estou vendo métricas de memória/uso de disco da minha instância EC2", a resposta é sempre instalar o CloudWatch Agent — nunca "aumentar a frequência de monitoramento" ou qualquer outra opção que não envolva o agente.

O mesmo CloudWatch Agent também pode coletar e enviar logs de dentro da instância (arquivos de log da aplicação, do sistema) para o CloudWatch Logs — sem ele, nada dentro do SO chega automaticamente ao CloudWatch.

2. Standard Monitoring vs Detailed Monitoring

Para EC2, existem dois níveis de frequência de coleta das métricas padrão:

  • Standard (padrão, sem custo extra): métricas coletadas a cada 5 minutos.
  • Detailed (opcional, com custo adicional): métricas coletadas a cada 1 minuto, permitindo reação mais rápida a mudanças (ex: um Auto Scaling reagindo a picos de CPU com menos atraso).

💡 Para métricas customizadas (enviadas via API ou CloudWatch Agent), é possível ir além, com resolução de até 1 segundo ("high-resolution metrics") — mas quanto maior a resolução, maior o custo de ingestão e armazenamento.

3. Métricas customizadas e namespaces

Um namespace é um container lógico para organizar métricas relacionadas (ex: AWS/EC2 para métricas nativas do EC2, CWAgent para as enviadas pelo agente, ou um namespace próprio como MinhaApp/Checkout para métricas de negócio customizadas, como "carrinhos abandonados por minuto").

Métricas customizadas são enviadas via API (PutMetricData) ou pelo CloudWatch Agent, e têm custo proporcional ao número de métricas e à resolução de coleta.

4. Alarms — estados e mecânica

Um alarme do CloudWatch não é só "ligado ou desligado" — ele tem três estados possíveis:

  • OK: a métrica está dentro do limite configurado.
  • ALARM: a métrica ultrapassou o limite configurado (por um número mínimo de períodos consecutivos, conforme configurado).
  • INSUFFICIENT_DATA: o alarme acabou de ser criado, ou a métrica parou de reportar dados recentemente — o CloudWatch não tem informação suficiente para decidir entre OK e ALARM.

💡 Pegadinha de prova: um alarme pode disparar uma ação também ao entrar em INSUFFICIENT_DATA, não só em ALARM — útil, por exemplo, para detectar quando uma instância parou de reportar métricas completamente (o que pode indicar que ela caiu).

4.1 Composite Alarms

Combinam o estado de múltiplos alarmes numa única regra lógica (ex: "dispare só se o alarme de CPU alta E o alarme de fila cheia estiverem ambos em ALARM ao mesmo tempo") — reduz ruído de notificações quando vários alarmes relacionados disparam pelo mesmo incidente subjacente.

4.2 Anomaly Detection

Em vez de um threshold fixo definido manualmente, o CloudWatch pode aprender o padrão normal de uma métrica ao longo do tempo (considerando sazonalidade, ex: tráfego naturalmente mais alto em horário comercial) e alarmar quando o valor foge significativamente desse padrão esperado — útil para métricas cujo "normal" varia previsivelmente ao longo do dia/semana, onde um threshold fixo geraria falsos positivos ou negativos.

5. Logs — estrutura e Logs Insights

  • Log Group: um agrupamento lógico de logs (ex: todos os logs de uma função Lambda específica, ou de uma aplicação).
  • Log Stream: dentro de um log group, uma sequência de eventos de log vindos de uma única fonte (ex: uma instância específica, uma execução específica de Lambda).
  • Retention Policy: por padrão, os logs nunca expiram (retenção indefinida, gerando custo crescente) — é preciso configurar explicitamente por quanto tempo manter cada log group.

CloudWatch Logs Insights permite rodar consultas ad-hoc sobre os logs, com uma linguagem de query própria (filtros, agregações, ordenação) — muito mais rápido que baixar e grepar manualmente arquivos de log brutos, e adequado para investigação pontual de incidentes (ex: "quantas requisições retornaram 500 na última hora, agrupadas por endpoint?").

5.1 Subscription Filters

Permitem encaminhar em tempo real logs que casam com um padrão específico para outro destino — como uma função Lambda (para processamento/alertas customizados), um stream do Kinesis, ou o OpenSearch Service (para indexação e busca avançada) — sem esperar alguém rodar uma query manualmente depois.

6. Alarms e automações

CloudWatch Alarms podem publicar em SNS (notificação simples), acionar automações via Systems Manager (SSM) Runbooks, ou invocar diretamente uma função Lambda para remediação automática — por exemplo, reiniciar um serviço, escalar recursos, ou abrir um ticket automaticamente.

7. CloudWatch Synthetics

Permite criar canaries: scripts (Node.js/Python) que simulam ações de um usuário real contra seus endpoints em intervalos regulares (ex: a cada 5 minutos, "acesse a homepage, faça login, confira se o carrinho abre") — detectando problemas de disponibilidade ou fluxo de negócio antes que um usuário real seja afetado e reclame, diferente de simplesmente medir se um endpoint responde 200.

8. Contributor Insights

Analisa logs (ou eventos) para identificar automaticamente os principais contribuintes de um determinado padrão — por exemplo, "quais os 10 IPs de origem que mais geraram erro 429 na última hora" ou "quais as top URLs mais lentas". Útil quando o problema não é "a métrica está ruim", mas "quero saber quem está causando isso", sem escrever a query manualmente do zero.

9. Dashboards

Painéis visuais combinando widgets de métricas (gráficos, números, tabelas) de múltiplas fontes e até múltiplas contas/regiões (com cross-account/cross-region dashboards), permitindo uma visão consolidada de operação sem precisar alternar entre consoles de contas diferentes.

10. Relação com EventBridge

Enquanto CloudWatch foca em métricas contínuas (números que sobem e descem ao longo do tempo) e logs, o Amazon EventBridge (evolução do antigo "CloudWatch Events") foca em eventos discretos — algo aconteceu uma vez (uma instância mudou de estado, um objeto foi criado no S3, um horário agendado chegou) e uma ação deve ser disparada em resposta. Os dois se complementam: um alarme do CloudWatch pode, inclusive, ser um dos gatilhos que o EventBridge escuta para orquestrar reações mais complexas.

11. Boas práticas

  • Instale o CloudWatch Agent sempre que precisar de métricas de memória, disco ou logs de dentro do SO.
  • Defina thresholds realistas e configure alarm actions automatizadas (SNS, Lambda, SSM).
  • Configure retention policy explícita em todo log group, evitando custo crescente indefinido.
  • Use composite alarms para reduzir ruído de notificações redundantes.
  • Use dashboards centralizados para visão de operação, especialmente cross-account/cross-region em ambientes multi-conta.
  • Use Synthetics para validar fluxos de negócio críticos, não só disponibilidade básica de endpoint.

12. Como cai na certificação

  • Cenário "não vejo métricas de memória/disco de uma instância EC2" → instalar o CloudWatch Agent.
  • Cenário "reagir mais rápido a picos de CPU, com granularidade de 1 minuto" → Detailed Monitoring.
  • Cenário "análise ad-hoc e filtros em grandes volumes de logs" → CloudWatch Logs Insights.
  • Cenário "acionamento automático com notificações" → Alarm + SNS.
  • Cenário "reduzir ruído de múltiplos alarmes relacionados disparando pelo mesmo incidente" → Composite Alarm.
  • Cenário "alarmar quando o comportamento foge do padrão esperado, considerando sazonalidade" → Anomaly Detection.
  • Cenário "encaminhar logs específicos em tempo real para processamento customizado" → Subscription Filter.
  • Cenário "simular fluxo real de usuário (login, checkout) periodicamente" → CloudWatch Synthetics (canaries).
  • Cenário "identificar automaticamente quem mais contribui para um padrão de erro" → Contributor Insights.
  • Cenário "reagir a um evento discreto (não métrica contínua), como criação de objeto no S3" → EventBridge, não CloudWatch Alarm.

13. Exercícios práticos conceituais

  1. Projete um conjunto mínimo de métricas e alarms para uma aplicação web com RTO de 30 minutos.
  2. Explique como usar Logs Insights para investigar picos de latência.
  3. Defina quando criar métricas customizadas versus usar métricas padrão, e o papel do CloudWatch Agent nessa decisão.
  4. Planeje retenção de logs e impacto de custo.
  5. Explique a diferença entre os três estados de um alarme e por que INSUFFICIENT_DATA pode ser um sinal de problema por si só.
  6. Compare Composite Alarms e Anomaly Detection — cada um resolve qual tipo de ruído/falso positivo?

14. Questões de Revisão

Questão 1

Qual ferramenta é mais indicada para consultas ad-hoc em grandes volumes de logs?

Questão 2

Você deseja acionar uma função Lambda automaticamente quando um alarm é disparado. Qual integração usar?

Questão 3

Qual é um cuidado ao criar métricas customizadas de alta resolução (1s)?

Questão 4

Para reduzir custos de logs, o que fazer?

Questão 5

Qual serviço é mais apropriado para monitoramento sintético de endpoints, simulando ações reais de usuário (ex: login e checkout)?

Questão 6

Uma equipe lança uma instância EC2 e espera ver, no console do CloudWatch, um gráfico de uso de memória RAM. A métrica não aparece em lugar nenhum, mesmo esperando várias horas. Qual é a causa mais provável e a correção?

Questão 7

Um alarme do CloudWatch acabou de ser criado para uma métrica customizada que ainda não recebeu nenhum dado. Qual é o estado inicial esperado do alarme?

Laboratório Prático

Objetivo: instalar o CloudWatch Agent numa instância EC2 para coletar memória, criar um alarme com os três estados observáveis, e rodar uma query no Logs Insights.

Pré-requisitos: uma instância EC2 (Amazon Linux) com uma IAM Role que inclua a policy CloudWatchAgentServerPolicy.

Tempo estimado: 30 minutos

Possíveis custos: praticamente nulo dentro do free tier para testes pontuais; atenção a métricas de alta resolução e retenção de logs se deixado ativo por muito tempo.

Passos:

  1. Confirme no console do CloudWatch que a instância já reporta CPUUtilization, mas não reporta nenhuma métrica de memória.
  2. Instale o CloudWatch Agent na instância (via SSM ou manualmente) e configure-o para coletar mem_used_percent e enviar logs de um arquivo de teste.
  3. Após alguns minutos, confirme no console que a métrica de memória agora aparece, num namespace customizado (CWAgent).
  4. Crie um Alarm sobre CPUUtilization, com threshold baixo o suficiente para disparar rapidamente sob carga simulada. Observe o estado inicial (INSUFFICIENT_DATA até haver dados suficientes, depois OK).
  5. Gere carga de CPU artificialmente (ex: um loop simples) e observe o alarme transicionar para ALARM.
  6. No CloudWatch Logs, use o Logs Insights para rodar uma query simples sobre o log group criado pelo agente (ex: contar quantas linhas contêm uma palavra específica na última hora).

Resultado esperado: você confirma na prática a diferença entre métricas nativas e métricas via agente, observa os três estados de um alarme em sequência, e executa uma query real no Logs Insights.

Limpeza dos recursos: remova o alarme de teste, desinstale o agente ou termine a instância, e ajuste/apague a retenção do log group criado.

Referências: