M04·05Observabilidade

CAPÍTULO 05

Observabilidade

CloudWatch, métricas customizadas, logs estruturados, alarmes e X-Ray — seus olhos e ouvidos na AWS.

Por Thiago Souza10 min de leituraAtualizado em 2026-05

Uma aplicação que você não consegue observar é como dirigir um carro com os olhos fechados. Pode dar certo por uns segundos, mas o desastre é questão de tempo. Observabilidade é o conjunto de práticas e ferramentas que respondem a três perguntas:

  • O que está acontecendo agora? (métricas)
  • O que aconteceu antes do problema? (logs)
  • Onde exatamente ocorreu o problema? (traces)

CloudWatch — O painel central

CloudWatch é o serviço de observabilidade nativo da AWS. Ele coleta métricas, logs, eventos e te permite criar alarmes e dashboards. Pense nele como o painel de instrumentos do seu carro: velocidade, RPM, temperatura, combustível, tudo em um lugar.

Métricas

Toda EC2 já envia automaticamente para o CloudWatch métricas como: CPUUtilization, NetworkIn, NetworkOut, DiskReadOps. O RDS envia: DatabaseConnections, FreeableMemory, ReadIOPS, WriteLatency. O ALB envia: RequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count.

Você também pode publicar métricas customizadas da sua aplicação:

go
// Go — publicando métrica customizada com AWS SDK v2
cfg, _ := config.LoadDefaultConfig(ctx, config.WithRegion("sa-east-1"))
cw := cloudwatch.NewFromConfig(cfg)
 
_, err := cw.PutMetricData(ctx, &cloudwatch.PutMetricDataInput{
    Namespace: aws.String("MyApp/Orders"),
    MetricData: []types.MetricDatum{{
        MetricName: aws.String("OrdersCreated"),
        Value:      aws.Float64(1),
        Unit:       types.StandardUnitCount,
        Dimensions: []types.Dimension{
            {Name: aws.String("Environment"), Value: aws.String("prod")},
        },
    }},
})

Logs

CloudWatch Logs guarda os logs da sua aplicação. Você instala o agente nas EC2 (ou usa drivers de log no ECS/EKS) e tudo o que você escreve no stdout vai parar lá, indexado, pesquisável e com retenção configurável.

Estrutura do CloudWatch Logs:

  • Log Group: uma "pasta". Geralmente um por aplicação (ex: /loja-do-joao/api).
  • Log Stream: um "arquivo" dentro do grupo. Geralmente um por instância ou container.
  • Log Events: cada linha de log com timestamp.
Sempre escreva logs em formato JSON estruturado: {"level":"error","requestId":"abc-123","userId":42,"msg":"timeout no pagamento","durationMs":3041}. Isso permite usar o CloudWatch Logs Insights para queries SQL-like nos seus logs.

Exemplo de query no CloudWatch Logs Insights:

fields @timestamp, level, msg, durationMs
| filter level = "error" and durationMs > 1000
| stats count() by msg
| sort count desc
| limit 20

Alarmes

Um alarme é uma regra: "se a métrica X passar de Y por Z minutos, faça W". O W pode ser: enviar email, disparar SMS, acionar Auto Scaling, executar Lambda.

Exemplos de alarmes essenciais para um backend:

  • CPU média > 80% por 5 minutos → escalar +1 EC2
  • HTTPCode_Target_5XX_Count > 10 em 5 minutos → avisar time no Slack
  • DatabaseConnections > 90% do limite → avisar DBA
  • FreeStorageSpace < 10 GB no RDS → alarme crítico

X-Ray — Tracing distribuído

Quando sua aplicação tem 5 microsserviços e algo demora 8 segundos, onde está o gargalo? O X-Ray rastreia a requisição por todos os serviços, mostrando o tempo gasto em cada chamada (banco, HTTP externo, fila). É essencial em arquiteturas distribuídas.

Os 3 pilares da observabilidade

PilarPergunta que respondeServiço AWS
MétricasAlgo está errado?CloudWatch Metrics
LogsO que aconteceu?CloudWatch Logs
TracesOnde está o gargalo?AWS X-Ray
CloudWatch Logs cobra por GB ingerido. Logar tudo em DEBUG em produção pode gerar uma fatura assustadora no fim do mês. Configure LogLevel diferente por ambiente (DEBUG em dev, INFO em prod). Configure retenção adequada (30 dias é padrão saudável para logs de aplicação; 1 ano para logs de auditoria).