CloudWatch: sua aplicação está tentando falar com você

Uma aplicação rodando na AWS está o tempo inteiro gerando informação sobre si mesma: o que processou, quanto tempo levou, o que deu errado. O CloudWatch é onde essa informação vai parar, mas log, métrica e alarme resolvem perguntas diferentes, e tratar os três como sinônimos é o motivo mais comum de alguém ficar perdido na primeira investigação.

Logs: o que aconteceu, em detalhe

CloudWatch Logs armazena as linhas de log emitidas pela aplicação, organizadas em Log Groups, geralmente um por aplicação ou componente, e dentro deles em Log Streams. É o nível mais granular de informação: útil para reconstruir exatamente o que uma requisição específica fez, mas caro de vasculhar manualmente quando o volume é grande.

Numa aplicação .NET, a forma mais comum de chegar log estruturado até o CloudWatch é via uma biblioteca de logging, como Serilog com o sink apropriado, ou via o AWS SDK para .NET diretamente. Log estruturado, em vez de string solta, é o que faz diferença real depois: com campos claros como RequestId, UserId ou StatusCode, dá para usar o CloudWatch Logs Insights para consultar como se fosse uma query, em vez de procurar padrão de texto manualmente.

Log.Information("Pedido {PedidoId} processado em {DuracaoMs}ms", pedidoId, duracao);

Métricas: números ao longo do tempo

CloudWatch Metrics guarda séries numéricas, e boa parte delas já chega automaticamente de serviços gerenciados da AWS, como uso de CPU de uma instância EC2 ou contagem de invocações de uma função Lambda. Métrica customizada é a que a própria aplicação decide publicar, via PutMetricData, para acompanhar algo que só faz sentido dentro daquele domínio específico: pedidos processados por minuto, taxa de erro de um endpoint específico, tempo de resposta de uma chamada a serviço externo.

A diferença prática entre log e métrica é o tipo de pergunta que cada um responde bem. “O que aconteceu na requisição X” é pergunta de log. “Como o tempo de resposta se comportou na última hora” é pergunta de métrica. Tentar responder a segunda pergunta filtrando log manualmente funciona, mas é ineficiente comparado a já ter aquele número agregado como métrica.

Alarms: a parte que efetivamente avisa alguém

Um Alarm monitora uma métrica contra um limite definido e dispara uma ação quando esse limite é ultrapassado, geralmente notificando via SNS ou acionando uma resposta automatizada. É a peça que transforma dado observado em alguma coisa acionável. Uma métrica sem alarme configurado só existe passivamente, esperando alguém abrir o painel para olhar; um alarme muda isso, empurrando o problema ativamente.

O detalhe que costuma passar despercebido é que um alarme mal calibrado é tão problemático quanto a ausência de alarme. Um limite baixo demais gera ruído constante, e ruído constante tem o efeito colateral de fazer qualquer pessoa começar a ignorar alertas, inclusive os que importam.

Onde os três se encontram

Uma investigação real normalmente percorre os três nessa ordem: o alarme avisa que algo está fora do esperado, a métrica mostra desde quando e com que intensidade, e o log entrega o detalhe específico do que aconteceu dentro daquela janela de tempo. Configurar só um dos três deixa uma lacuna real: log sem métrica dificulta enxergar tendência, métrica sem alarme exige alguém olhando ativamente, e qualquer um dos dois sem log estruturado o suficiente deixa a causa raiz sem explicação clara quando o número finalmente aponta um problema.