trilha

AWS SAA-C03/10 - Observabilidade e Governança2 min

CloudWatch

Perguntas-guia

Responda com suas palavras antes de ler o resto da nota.

  • Que problema isso resolve?
  • Quando usar / quando NÃO usar?
  • Qual o principal trade-off (custo, latência, operação)?
  • Que sinal no enunciado aponta pra isso?
  • Com o que isso é confundido na prova?

Conceito

Plataforma de observabilidade: métricas, logs, alarmes e dashboards. Responde "como está performando?" — nunca "quem fez o quê" (isso é CloudTrail).

Métricas

  • Namespace + nome + dimensões (ex: AWS/EC2 / CPUUtilization / InstanceId)
  • EC2 básico: a cada 5 minutos (grátis). Detailed monitoring: 1 minuto (pago)
  • Custom metrics: resolução padrão 60 s, high-resolution até 1 segundo
  • Retenção: 15 meses, com agregação progressiva
Memória e disco não são nativos

O EC2 não publica métrica de memória nem de espaço em disco — o hipervisor não enxerga dentro do SO. É preciso instalar o CloudWatch Agent. Essa é uma das perguntas mais recorrentes do domínio de monitoramento.

Logs

Peça O que é
Log group / log stream Organização dos logs
CloudWatch Agent Envia logs e métricas do SO (EC2 e on-premises)
Logs Insights Query ad-hoc sobre os logs
Metric filter Extrai métrica de um padrão no log (ex: contar ERROR) → vira alarme
Subscription filter Streaming dos logs para Lambda, Kinesis, OpenSearch
Retenção Configurável (1 dia a "para sempre") — reduzir retenção é economia direta

Alarmes

Estados: OK, ALARM, INSUFFICIENT_DATA. Ações: SNS, Auto Scaling, EC2 stop/terminate/reboot, Systems Manager. Composite alarms combinam alarmes para reduzir ruído.

Outros

Synthetics Canaries (monitoramento sintético de endpoint), X-Ray (tracing distribuído, mostra o gargalo entre microserviços), Container Insights e Lambda Insights.

Trade-offs

Métrica detalhada de 1 minuto e log com retenção longa custam — em frota grande a fatura do CloudWatch surpreende. Reduzir retenção, filtrar o que se envia e usar metric filter em vez de guardar tudo são as alavancas de economia.

CloudWatch mostra o que está ruim; X-Ray mostra onde, dentro de uma requisição que passa por vários serviços. Se o enunciado fala em "identificar qual microserviço está causando a latência", é X-Ray.

Sinais de prova

  • "Alertar quando a CPU passar de 80%" → CloudWatch Alarm + SNS
  • "Monitorar uso de memória de EC2" → CloudWatch Agent
  • "Contar erros no log e alarmar" → metric filter + alarm
  • "Consultar logs de forma ad-hoc" → Logs Insights
  • "Enviar logs em tempo real pro OpenSearch" → subscription filter
  • "Achar o gargalo entre microserviços" → X-Ray
  • "Testar se o site responde de fora" → Synthetics Canary
  • "Reduzir custo do CloudWatch" → retenção de log e resolução da métrica

Relacionado


Parte de 10 - MOC Observabilidade e Governança · Documentação AWS

Buscar

Busca por título, seção e texto das notas