Os Três Pilares da Observabilidade: Logs, Métricas e Traces

Há uma diferença sutil e decisiva entre monitoramento e observabilidade, e confundir os dois leva equipes a gastarem fortunas em ferramentas sem nunca conseguirem responder à pergunta que importa quando o sistema está pegando fogo às três da manhã. Monitoramento responde perguntas que você sabia que ia fazer: a CPU está alta? O disco está cheio? A taxa de erro passou do limite? Você configurou esses alertas de antemão porque previu esses problemas.

Observabilidade é outra coisa. É a propriedade de um sistema que permite responder perguntas que você não previu, a partir dos dados que ele já emite, sem precisar mudar o código e fazer um novo deploy. Quando um problema novo aparece, um que ninguém antecipou, um sistema observável deixa você investigar e descobrir a causa navegando pelos dados existentes. Um sistema apenas monitorado te deixa cego para tudo que não foi previsto. E os incidentes que mais doem são justamente os que ninguém previu.

Os três pilares que sustentam a observabilidade são logs, métricas e traces. Cada um responde a uma classe de pergunta, tem custos e limitações próprios, e brilha quando combinado com os outros. Entender o que cada pilar faz bem, e o que faz mal, é o que separa uma estratégia de observabilidade que funciona de uma pilha de ferramentas caras que ninguém sabe usar na hora do aperto.

Métricas: baratas, agregadas, sem detalhe#

Uma métrica é um número medido ao longo do tempo. Requisições por segundo, latência no percentil 99, uso de memória, tamanho de uma fila. Métricas são séries temporais: valores associados a instantes, tipicamente coletados a intervalos regulares e guardados de forma compacta.

A grande virtude das métricas é a eficiência. Como são apenas números agregados, ocupam pouco espaço e permitem guardar longos históricos por um custo baixo. É barato manter meses ou anos de métricas, o que as torna ideais para enxergar tendências, capacidade e sazonalidade. São também a base natural dos alertas: "dispare se a latência p99 passar de 500ms por cinco minutos" é uma regra sobre uma métrica.

A limitação é o outro lado da mesma moeda. Métricas são agregadas por natureza, e a agregação apaga o detalhe. Uma métrica te diz que a latência média subiu, mas não te diz qual requisição foi lenta, para qual usuário, por qual motivo. Ela aponta que existe um problema e mais ou menos onde, mas não conta a história de um caso individual. Métricas são o alarme, não a investigação.

Aqui aparece o conceito que mais causa contas explosivas: cardinalidade. Métricas ganham dimensões por meio de labels, como o método HTTP, a rota, o código de status. Cada combinação distinta de labels cria uma série temporal separada. Adicionar um label de baixa cardinalidade, como o método (poucos valores possíveis), é barato. Adicionar um label de alta cardinalidade, como o ID do usuário ou o ID da requisição (milhões de valores), multiplica o número de séries por milhões e faz o sistema de métricas explodir em custo e lentidão. A regra de ouro é firme: métricas são para dados de baixa cardinalidade. Identificadores únicos não entram em labels de métrica; eles pertencem aos logs e aos traces.

Logs: detalhados, contextuais, caros em volume#

Um log é um registro de um evento que aconteceu, num momento específico, com contexto. "Requisição recebida", "conexão com o banco falhou", "usuário X fez a ação Y". Logs são a forma mais antiga e mais intuitiva de observabilidade, e continuam insubstituíveis para uma coisa: contar o que exatamente aconteceu em um caso específico.

Onde as métricas agregam, os logs preservam o detalhe. Um log carrega a mensagem, o instante, e todo o contexto que você anexar: qual usuário, qual requisição, qual valor do parâmetro que causou o erro. Quando você precisa entender por que aquela requisição específica falhou, é no log que a resposta está.

A grande evolução prática dos logs é o log estruturado. Um log em texto livre, como uma frase solta, é fácil de escrever e difícil de consultar em escala. Um log estruturado é um registro com campos nomeados, tipicamente em JSON, com chaves como nivel, mensagem, usuario_id, duracao_ms, trace_id. A diferença é que o log estruturado é pesquisável e filtrável por campo: você consegue perguntar "me mostre todos os logs de erro do usuário X na última hora com duração acima de um segundo" e obter resposta, o que é impossível com texto livre sem heroísmos de expressão regular.

O custo dos logs é o volume. Sistemas movimentados geram quantidades imensas de logs, e armazenar e indexar tudo fica caro rápido. Isso força decisões: amostrar logs de alto volume, definir retenções mais curtas para logs verbosos, escolher com cuidado os níveis (não logar em nível debug em produção o tempo todo). Logs são o pilar mais rico em contexto e o mais caro em escala, e usá-los bem é uma questão de disciplina sobre o que merece ser registrado.

Traces: o mapa da jornada de uma requisição#

O terceiro pilar é o que falta para investigar sistemas distribuídos, e é o menos compreendido dos três. Um trace representa a jornada completa de uma requisição atravessando os vários serviços de um sistema.

Numa arquitetura de microsserviços, uma única requisição do usuário pode passar por um gateway, um serviço de autenticação, um serviço de catálogo, um de pagamento, tocando bancos e caches pelo caminho. Quando essa requisição fica lenta, a pergunta crucial é: onde exatamente o tempo foi gasto? As métricas de cada serviço, isoladas, não respondem, porque nenhuma delas vê a requisição inteira. O log de cada serviço conta um pedaço, mas costurar os pedaços à mão é inviável.

O trace resolve isso amarrando tudo. Cada operação dentro da jornada vira um span, com início, fim e duração, e os spans se organizam numa hierarquia que mostra o que chamou o quê e quanto cada etapa demorou. O que costura os spans de serviços diferentes num único trace é a propagação de contexto: um identificador de trace que nasce na borda e é passado adiante em cada chamada entre serviços, tipicamente em cabeçalhos HTTP. Assim, o gateway, o serviço de autenticação e o de pagamento carregam todos o mesmo trace_id, e a ferramenta de tracing reconstrói a jornada completa a partir dele.

O trace é o pilar que responde "onde está o gargalo" num sistema distribuído. Ele mostra, em uma linha do tempo, que a requisição gastou vinte milissegundos na autenticação, cinco no catálogo e trezentos esperando o banco do serviço de pagamento. Sem trace, essa conclusão exige adivinhação; com trace, ela salta aos olhos.

Os pilares se completam, não competem#

O erro estratégico é tratar os três pilares como alternativas e escolher um. Eles são complementares, e o valor real aparece na costura entre eles.

O fluxo ideal de investigação percorre os três em sequência. Um alerta baseado em métrica dispara: a taxa de erro do serviço de pagamento subiu. A métrica te diz que há um problema e onde, mas não por quê. Você pula para os traces das requisições com erro e vê que todas travam na mesma chamada ao banco. O trace te leva ao ponto exato da falha. Ali, você abre os logs daquele span específico e lê a mensagem detalhada: um timeout de conexão com uma mensagem de erro concreta. Métrica para detectar, trace para localizar, log para diagnosticar. Cada pilar entrega o que o próximo precisa.

O que torna essa costura possível é a correlação por identificadores compartilhados. Quando o trace_id aparece nos logs, você salta do trace direto para os logs certos. Quando a métrica carrega um exemplar apontando para um trace representativo, você salta da métrica para o trace. Sem esses fios de ligação, você tem três silos de dados e precisa correlacioná-los na cabeça sob pressão. Com eles, você navega de um pilar a outro em segundos.

Padrões abertos e o custo de instrumentar#

Uma preocupação legítima ao adotar observabilidade é o aprisionamento a um fornecedor: se você instrumenta seu código com a biblioteca proprietária de uma ferramenta, trocar de ferramenta depois significa reinstrumentar tudo. A resposta a esse problema é a padronização.

O OpenTelemetry emergiu como o padrão aberto para instrumentação. Ele define APIs e SDKs neutros para gerar logs, métricas e traces, e um protocolo comum para exportá-los. A vantagem é o desacoplamento: você instrumenta a aplicação uma vez, seguindo o padrão, e escolhe separadamente para onde enviar os dados. Trocar o backend de observabilidade deixa de exigir tocar no código. A instrumentação, que é o trabalho caro, fica protegida da escolha de ferramenta, que é o que muda com o tempo.

Vale reconhecer que instrumentar tem custo. Bom código de observabilidade é código que você escreve deliberadamente: métricas com labels pensados para não explodir a cardinalidade, logs estruturados com contexto útil, spans nos pontos certos da jornada. Não é gratuito, e não vem sozinho. Mas é o que transforma um sistema opaco, onde cada incidente é uma escavação arqueológica, em um sistema onde as respostas estão a poucos cliques de distância.

De observar a confiar#

Observabilidade não é um fim em si. Ela existe para sustentar decisões: quando escalar, quando reverter, quando um comportamento é normal ou anômalo. E é a matéria-prima de uma prática mais ampla, a de definir e medir objetivos de confiabilidade com números em vez de sensações. Os sinais que você coleta com os três pilares alimentam diretamente os indicadores que a engenharia de confiabilidade usa para decidir onde investir esforço, um tema que exploramos ao tratar de SLIs, SLOs e error budgets.

No fim, a diferença entre monitorar e observar é a diferença entre ser surpreendido pelos problemas que você previu e ser capaz de entender os que você não previu. Sistemas complexos falham de formas complexas, e nenhuma quantidade de alertas antecipa tudo. Observabilidade é a aposta de que, quando o inesperado acontecer, você terá nas mãos os dados para entendê-lo, em vez de ter apenas a certeza vazia de que algo está errado.