📌 Material de chegada: caderno de bordo com 3 perguntas que o MVP não responde + 1 frase sobre error budget. Esses 4 itens alimentam o daily de abertura.
Logs estruturados (JSON) · Métricas RED+USE · Distributed tracing com OpenTelemetry · dashboards · SLO/error budget · custos.
Subir a infra do MVP na nuvem (AWS) com o AIOX: o @devops gera o CloudFormation e faz o deploy. Documentar em docs/deploy.md.
aws configure)infra.yml gerado pelo @devops (CloudFormation)🎯 Saída do dia: Merge Request no repositório do grupo com o infra.yml + a URL pública do serviço no ar + docs/deploy.md. Não é ponderada — é prática boa em sala. À tarde a equipe segue para a retrospectiva da sprint.
| Aspecto | 📜 Logs | 📊 Métricas | 🔗 Traces |
|---|---|---|---|
| Pergunta-chave | O que aconteceu? | Quanto / com que frequência? | Por onde a requisição passou? |
| Granularidade | Evento individual | Agregado temporal | Por requisição |
| Custo de armazenamento | Alto (texto cresce) | Baixo (números) | Médio (sample) |
| Cardinality | Qualquer campo | Limitada (labels) | Tags por span |
| Retenção típica | 7-30 dias hot | 13 meses | 3-7 dias |
| Uso típico | Auditoria, debug pontual | Dashboard, alertas, SLO | Latência cross-service |
| Stack comum | Serilog → ELK / Loki | OTel → Prometheus → Grafana | OTel → Jaeger / Tempo |
Eventos textuais com contexto. Verbosos, ricos, caros.
Números agregados no tempo. Baratas, ótimas para alerta.
Reconstroem a jornada da requisição entre serviços.
Não dá pra filtrar por userId, agregar por latency, alertar quando >500ms.
@t · timestamp ISO-8601 UTClevel · Trace/Debug/Info/Warning/Error/FataltraceId · correla logs cross-serviceuserId · contexto de domíniomsg · template humano💡 Regra do Inteli: nada de Console.WriteLine em produção. Toda mensagem de log é um evento de domínio com templates nomeados — Serilog mantém template e valores separados, e isso vira coluna pesquisável no ELK.
Para o Recommendation Service: chamadas/seg, % de erros 500, p95 da resposta.
Para a VM/Container: CPU%, throttling, OOM kills.
📦 Stack canônica: System.Diagnostics.Metrics (.NET) → OpenTelemetry SDK → Prometheus (scrape) → Grafana (visualização). OTel é a interface neutra; troca de backend sem mexer no código.
Trace = uma operação ponta-a-ponta (ex.: GET /recommendations). Span = um pedaço dessa operação (ex.: chamada ao DB, ao cache, ao serviço de ranking). Cada span tem traceId, spanId, parentSpanId e tags.
3 serviços · OTel envia para Jaeger · você clica e vê onde queimou tempo.
🔍 Olhar: a barra vermelha do ranker.svc é a maior — é lá que tem que cortar latência, não no DB.
📐 Princípio: 1 tela = 1 pergunta. Dashboard com 47 gráficos = ninguém olha. Quebre por persona (operador on-call · PM · arquiteto) e por fluxo (checkout · login · home).
Cada combinação única de labels = uma série temporal. Adicionar userId como label numa métrica com 1M de usuários = 1M de séries · explode o Prometheus.
Regra: labels devem ter poucos valores possíveis. userId vai pra log/trace, não pra métrica.
Não armazena 100% dos traces (caro demais). Estratégias:
⚠️ Anti-padrão clássico: mandar todo log de DEBUG para ELK 24×7. Em uma semana o budget de observabilidade dobra o do compute. Filtre antes de enviar (Vector, Fluent Bit, processador OTel).
O erro nasce no Database (timeout), mas explode no app do usuário. Quem atende o chamado vê o 500 do gateway — três serviços de distância da causa.
Cada serviço só enxerga o próprio log, na própria máquina. Correlacionar é cavar por horário — com relógios que nem batem entre si (clock skew).
"No meu serviço está tudo verde." Sem visão da jornada, o MTTR dispara: horas de war-room para achar o que uma busca certa acharia em minutos.
🪡 O remédio: um fio que costura a jornada inteira — um id único que nasce na borda e viaja com a requisição por todos os serviços. É o traceId → próximo slide.
traceparent · um id que atravessa toda a jornadaFormato padronizado pelo W3C · todas as bibliotecas OTel injetam e leem. Frontend → API Gateway → Reco Service → DB · todos compartilham o mesmo trace-id.
Em .NET com OTel o HttpClient instrumentado já injeta traceparent nas chamadas saintes. ASP.NET extrai do header de entrada. Você só precisa abrir spans dentro do código.
Um usuário reporta "lento às 14h32". Você acha 1 trace lento → pega o traceId → busca todos os logs daquele traceId em todos os serviços → reconstrói a jornada inteira em <1 min.
Configurar a AWS CLI no terminal (aws configure) e validar com aws sts get-caller-identity. Credencial fora do git.
Descrever a infra em 1 frase e deixar o @devops (AIOX) gerar o template CloudFormation da API .NET.
Deploy via cloudformation deploy · API no App Runner com URL pública respondendo de verdade.
docs/deploy.mdComo subir · print da stack criada e da URL no ar · custo estimado da infra.
📌 Entrega: Merge Request no repositório do grupo com:
feat/infra-aws com o infra.yml (CloudFormation versionado)docs/deploy.md com prints anexados (stack CREATE_COMPLETE + a URL pública respondendo)⭐ Excelência: pipeline de CI/CD que roda o cloudformation deploy a cada merge na main (deploy automático) + healthcheck da URL. Quem entregar isso ganha menção honrosa na retrospectiva.
@devops (Gage) do AIOX gera o template e aplica via terminalaws configure + sts get-caller-identityinfra.yml (CloudFormation)@devops *push dispara o CI/CD → cloudformation deploy⚖️ Regra do AIOX: a IA gera o infra.yml, mas você revisa antes de aplicar (IAM mínimo, porta exposta, custo). O push/deploy é autoridade exclusiva do @devops — credenciais ficam como secret no CI, nunca na máquina do dev.
feat/infra-aws a partir da mainaws configure + aws sts get-caller-identity@devops (Gage) no Claude Code@devops gera o infra.ymlvalidate-template + @devops *push (deploy)infra.yml com o @devops, outro revisa o template, outro testa a URL. Quem terminar cedo pluga a observabilidade da aula."O recomendador saiu da matemática e virou produto observável em produção."
Daqui pra frente o módulo segue com outro professor. E vem a Sprint Review do parceiro Aventura: tudo o que você construiu precisa virar uma demo de 5 minutos.