Observability enterprise: CloudWatch, X-Ray, OpenSearch
- ⬜📋 Governance e compliance: Config, Audit Manager, Artifact(AWS Solutions Architect Professional (SAP-C03))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Três pilares: metrics, logs, traces
Metrics (what):
CloudWatch Metrics (managed + custom)
CloudWatch Metric Streams → Kinesis → Datadog/Grafana
Amazon Managed Prometheus (AMP)
CloudWatch Dashboards / Managed Grafana
Logs (why):
CloudWatch Logs (ingest + retenção + Insights)
Subscription filter → Firehose → S3/OpenSearch
OpenSearch Service (indexed, dashboard full-text)
S3 + Athena pra archival + query SQL
Traces (how):
AWS X-Ray (SDK per runtime)
OpenTelemetry + ADOT (AWS Distro for OpenTelemetry)
Service Map pra visualização
Correlação com métricas via ServiceLens
Cross-cutting:
Application Insights (auto-detect apps tradicionais)
Container Insights (ECS/EKS)
Lambda Insights (runtime metrics profundas)
Synthetics (canaries HTTP externos)
RUM (Real User Monitoring browser/mobile)- → instrumenta
- → métrica e log
- → trace
- → compartilha
- → assinatura de log
- → painel único
- → desvio
- → aciona
- Compute
- Gestão e governança
- Analytics
- IA e machine learning
- Integração de apps
Em escala de organização a pergunta não é "quais métricas", é "onde o on-call olha às 3h da manhã". Cross-Account Observability responde isso; alerta por SLO evita que ele acorde por nada.
- Instrumente com OpenTelemetry. Padrão neutro: a mesma instrumentação alimenta CloudWatch, X-Ray ou ferramenta de terceiro. Evita reinstrumentar a aplicação se a ferramenta mudar — argumento que o SAP valoriza.
- Três pilares, e eles se completam. Métrica diz QUE está ruim, log diz O QUE aconteceu, trace diz ONDE o tempo foi. Investigar com só um dos três é o que faz incidente durar horas.
- Cross-Account Observability resolve o multi-conta. Contas fonte compartilham com uma conta monitor, e o painel fica num lugar só. Sem isso, o on-call abre N consoles durante um incidente — e é justamente quando ele não tem tempo.
- Alerte por SLO, não por CPU. CPU a 90% pode ser normal. Latência p99 acima do orçado é problema do usuário. Alarme em métrica de infraestrutura gera ruído; alarme em SLO gera ação. Anomaly Detection substitui limiar fixo por baseline aprendido.
- Log quente e log frio custam diferente. CloudWatch Logs para o recente e consultável; assinatura para OpenSearch ou S3 para retenção longa e busca livre. Guardar tudo em CloudWatch por anos é decisão de custo ruim.
Onde isso entra no exame
A questão descreve um sintoma em produção e pede o sinal certo. Separe métrica (tendência), log (evento) e trace (caminho) — e saiba como agregar isso vindo de N contas: CloudWatch cross-account observability, em vez de um dashboard por conta ou de copiar log entre contas.
Pipeline padrão de logs em escala
App Lambda / ECS / EC2
│
▼ CloudWatch Logs (retention 7d, custo baixo)
│
├─► Subscription filter (pattern ERROR|WARN)
│ │
│ ▼ Kinesis Data Firehose
│ │ ├─► S3 (archival parquet, Athena query)
│ │ └─► OpenSearch Service (indexed, dashboards)
│
└─► Metric Filter (count ERROR/min)
│
▼ CloudWatch Metric + Alarm → SNS → PagerDuty
Retenção:
CloudWatch Logs: 7 dias (hot)
OpenSearch: 30 dias (warm, searchable)
S3 Standard: 90 dias
S3 Glacier Deep Archive: 7 anos (compliance)Numa organização com 40 contas, o on-call precisa investigar um incidente que atravessa 3 contas. Qual recurso evita abrir 3 consoles?
Observability que paga o próprio custo
Stack maduro inclui SLOs definidos (ex: p99 latency < 500ms, error rate < 0.1%), alarmes só em violação de SLO (elimina alert fatigue), dashboards por serviço padronizados (golden signals: latência, tráfego, erros, saturação), correlação traces+logs+metrics via request ID, auto-remediation em incidentes conhecidos.
Regra: sem observability, DR é fake, autoscaling é chute, SLA é promessa. Investimento de 2-5% do gasto total em CloudWatch + OpenSearch + AMP paga em MTTR reduzido e postmortems acionáveis.
Perguntas frequentes
❓ Como centralizar observabilidade em várias contas?
❓ Métrica, registro ou rastro: por onde começar?
❓ Quanto tempo guardar registro?
Fixando
Por que alertar sobre SLO em vez de CPU?
Qual é a vantagem de instrumentar com OpenTelemetry em vez de SDK proprietário?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…