🇧🇷O artigo está em PT-BR, fique à vontade para traduzir.
🇺🇲The article is in PT-BR, feel free to translate it.
☁️☁️☁️
Acabei de concluir o laboratório Introduction to Monitoring AWS with Datadog e quero compartilhar o que aprendi, porque foi bem mais interessante do que eu esperava. E também porque tive algumas dúvidas que acho que muita gente iniciante também teria.
Antes de começar, vou ser honesto: eu sei o que a AWS soluciona e entrega e tinha uma noção vaga do que era o Datadog ("aquela ferramenta de monitoramento cara"). Mas não entendia como os dois se conectavam na prática, nem por que isso seria importante no dia a dia de um time de DevOps.
O curso usa um app fictício chamado TechStories, uma plataforma de notícias e mídia social hospedada inteiramente na AWS, como base para os exercícios. Isso ajudou muito, porque deu um contexto real pra tudo.
O problema que o curso resolve
Imagine que seu time mantém uma aplicação rodando em EC2, com containers no ECS Fargate, banco de dados no RDS, funções Lambda e tabelas no DynamoDB. Como você sabe se está tudo funcionando bem? Você fica alternando entre console da AWS, CloudWatch, logs espalhados, é muito caótico.
O Datadog entra como uma camada única de observabilidade: você coleta métricas, logs e traces de tudo isso em um só lugar. O lab simulou exatamente esse cenário.
Como a integração AWS funciona por baixo dos panos
A primeira coisa que o curso explica é que existem basicamente dois jeitos de coletar dados da AWS no Datadog:
Via polling do CloudWatch — o Datadog consulta a API da AWS de tempos em tempos pra pegar as métricas. É a forma mais simples de configurar, mas tem um delay de alguns minutos.
Via Metric Streams — você configura a AWS pra empurrar as métricas pro Datadog em tempo quase real. Latência bem menor, ideal pra alertas críticos.
Na prática, pra começar você instala a integração AWS no Datadog, cria uma role IAM na sua conta com as permissões corretas, e aponta o Datadog pra essa role. Depois disso ele já começa a descobrir os recursos automaticamente.
O Datadog Forwarder e o negócio dos logs
Uma das partes que mais me fez parar e reler foi o fluxo de logs. Na AWS, os logs dos serviços gerenciados (Lambda, RDS, etc.) vão pro CloudWatch Logs. Mas o Datadog não lê o CloudWatch Logs diretamente, você precisa de um intermediário.
Esse intermediário é o Datadog Forwarder: uma função Lambda que você instala via CloudFormation e que fica "ouvindo" os CloudWatch Log Groups. Quando chega um log novo, ela encaminha pro Datadog. É bonito quando está pronto, mas exige configurar subscriptions pra cada log group que você quer monitorar.
No lab, depois de configurar isso, consegui ver os logs da Lambda keyword-insights-processor direto no Log Explorer do Datadog, com todos os campos estruturados, tags automáticas de ambiente, serviço, ARN da função, etc. Bem diferente de ficar vasculhando no CloudWatch.
Datadog Agent: quando os serviços gerenciados não são suficientes
Pra EC2 e containers, o Datadog tem o próprio agente, um processo que roda dentro da máquina/container e coleta métricas muito mais granulares do que o CloudWatch oferece: memória por processo, latência de disco, métricas customizadas, traces...
No caso do ECS Fargate, você sobe o Agent como um sidecar container na mesma task definition do seu serviço. Quando vi isso me pareceu muito trabalhoso, mas no lab eles mostram que dá pra fazer via CloudFormation, e as tags ficam todas consistentes por causa de um padrão de key:value definido nos recursos:
App:TechStories / Env:monitoring-aws-lab / Service:<nome-do-serviço>
Isso é fundamental. Sem tags consistentes, você não consegue filtrar nada no Datadog depois.
O que dá pra ver depois que tudo está integrado
O Resource Catalog mostrou tudo que foi descoberto na conta: 343 databases, 70 containers, 22 serverless functions, 1 host EC2... tudo categorizado, com região, ambiente e serviço associado. Dá pra clicar em qualquer recurso e ver as métricas diretamente.
Na seção de Metrics, busquei por aws.dynamodb e apareceram 22 métricas diferentes — capacidade de leitura/escrita, número de itens, tamanho das tabelas. Coisas que antes eu teria que montar dashboards manualmente no CloudWatch.
O AWS Overview Dashboard, que vem pronto como OOTB (out-of-the-box) no Datadog, já trouxe um panorama geral: 1 instância EC2 rodando, 4 monitores de status todos OK, 491 invocações Lambda na última hora, taxa de erro 0%, duração média de 988ms. Também dá pra ver traces das requisições HTTP diretamente no host EC2: cada request com host, serviço, recurso e latência.
O que ficou de lição 🧠
Mais do que as ferramentas em si, o lab reforçou uma coisa: observabilidade não é sobre acumular dados. É sobre ter os dados certos, com contexto suficiente (tags!) pra você conseguir responder perguntas quando algo dá errado.
A integração AWS + Datadog, quando bem configurada, te dá isso: um lugar só pra métricas, logs e traces, com correlação entre eles. Você vê que o tempo de resposta subiu, clica no trace, chega no log do Lambda, entende o que aconteceu.
Ainda tenho muito a aprender (APM, alertas, SLOs...), mas foi uma ótima base. Recomendo o Learning Center do Datadog pra quem quiser começar, os labs são práticos e o ambiente já vem configurado, então você foca no aprendizado em vez de ficar lutando com IAM.
Se quiser trocar ideia sobre isso ou acompanhar minha jornada, me encontra aqui no LinkedIn ✌️
Top comments (0)