AWS Observability — CloudWatch, X-Ray e OpenTelemetry
Tres pilares (logs, metrics, traces), OTel em .NET 8, ADOT Collector, e como diagnosticar em 5 minutos
Padrao .NET 8 + AWS em 2024-2025: aplicacao usa OpenTelemetry SDK e exporta via OTLP para o ADOT Collector (AWS Distro for OpenTelemetry). O Collector encaminha traces para X-Ray e metrics para CloudWatch. Voce nao instala um exportador X-Ray dentro da app — esse era o pattern antigo.
Logs, Metrics e Traces — para que serve cada
| Logs | Metrics | Traces | |
|---|---|---|---|
| Pergunta que responde | "O que aconteceu nesse request especifico?" | "Como esta o sistema agora? Aggregada." | "Por onde passou esse request? Quanto demorou em cada hop?" |
| Granularidade | Por evento | Agregado em janelas | Por request, com hops |
| Custo | Alto (todo evento armazenado) | Baixo (so numero + timestamp) | Medio (amostrado normalmente) |
| Latencia ao consultar | Lenta (Logs Insights query) | Rapida (time-series) | Media (X-Ray service map) |
| Servico AWS | CloudWatch Logs | CloudWatch Metrics | X-Ray |
| Quando usar | Debug pos-incidente, audit | Dashboards, alarms | Localizar gargalo em dist sys |
Regra que economiza dinheiro: nao use logs para o que metric ja responde. Loggar "request received" em todo endpoint para depois contar via Logs Insights e ~50x mais caro que um
Counter em metric. Logs para contexto rico em eventos especificos; metrics para tendencias e thresholds; traces para localizar o hop lento.