Observabilidade em serverless: começando com CloudWatch

Existe um momento clássico no aprendizado de serverless: você deploya uma Lambda, a API responde, tudo parece funcionar. Aí chega um usuário relatando erro e você não sabe por onde começar a investigar.

Esse é o problema que observabilidade resolve. E no ecossistema AWS, o ponto de entrada para isso é o CloudWatch.

Uma arquitetura simples de API serverless geralmente segue o caminho Client → API Gateway → Lambda → DynamoDB. Cada um desses componentes pode falhar de formas diferentes: a Lambda pode lançar uma exceção, o API Gateway pode estar recebendo mais requisições do que o esperado, o DynamoDB pode estar adicionando latência que ninguém percebeu. Sem visibilidade, você está operando no escuro.

O CloudWatch é o serviço que agrega logs, métricas e alarmes desse ambiente. Não é a ferramenta mais sofisticada disponível, mas é a que já está lá, integrada por padrão com os serviços que você está usando.

Toda execução de uma Lambda pode gerar logs no CloudWatch. Eles capturam o que aconteceu durante aquela invocação: erros, tempo de execução, saídas do seu código. Quando algo falha, os logs são o ponto de partida da investigação.

Um detalhe que faz diferença desde cedo: logar com contexto útil. Um log que diz apenas error: undefined não ajuda muito. Um log que inclui o ID da requisição, o input que chegou e o estado da aplicação no momento do erro reduz bastante o tempo de debug. Ao mesmo tempo, evite logar dados sensíveis como tokens, senhas ou informações pessoais de usuários.

Logs contam o que aconteceu em uma execução específica. Métricas contam como o sistema está se comportando ao longo do tempo. Para Lambda, as mais relevantes no começo são Invocations, Errors, Duration e Throttles.

Invocations mostra o volume de requisições. Errors mostra quantas falharam. Duration mostra quanto tempo cada execução está levando. Throttles aparecem quando a função está sendo limitada pelo número de execuções simultâneas permitidas. Um aumento repentino em Errors, por exemplo, pode indicar uma mudança de código que quebrou algo, uma dependência externa com problema ou um novo padrão de input que seu código não trata.

Monitorar manualmente não é operação, é torcer para não ter problema. CloudWatch Alarms permitem que você defina um threshold para uma métrica e receba uma notificação quando ele for ultrapassado. O caso mais direto para quem está começando é um alarme para quando a taxa de erros da Lambda ultrapassar um valor aceitável.

O cuidado aqui é calibrar bem os thresholds. Alarmes sensíveis demais geram ruído e você começa a ignorá-los, que é exatamente o oposto do que você quer. Comece conservador e ajuste conforme entende o comportamento normal da sua aplicação.

Para uma API com API Gateway, Lambda e DynamoDB, o mínimo que faz sentido configurar logo no começo é monitorar volume e latência no API Gateway, acompanhar invocations e errors na Lambda, revisar os logs quando uma falha ocorrer e criar pelo menos um alarme para erros acima de um threshold definido.

Para aplicações que crescem e envolvem múltiplos serviços, AWS X-Ray complementa bem o CloudWatch adicionando rastreamento distribuído: você consegue ver o caminho completo de uma requisição e identificar exatamente onde a latência está aparecendo.

Deployar uma aplicação e operar uma aplicação são desafios diferentes. Uma Lambda que funciona no seu ambiente local pode ter comportamentos inesperados em produção sob carga real, com inputs reais e dependências reais. CloudWatch não elimina esses problemas, mas dá o contexto necessário para investigá-los sem depender de sorte ou de reproduzir o bug manualmente.

Começa simples: ativa os logs, olha as métricas básicas, cria um alarme. Esse é o passo que separa deployar de operar.