O que é observabilidade? Logs, métricas, traces e healthchecks
Entenda observabilidade a partir de logs, métricas, traces, healthchecks e alertas, e veja como esses sinais ajudam a explicar o comportamento real de um sistema.
Quando um sistema falha em produção, a primeira reação costuma ser abrir logs. Às vezes isso resolve. Em outros casos, você encontra milhares de linhas e nenhuma resposta clara.
A pergunta mais importante é anterior:
o sistema emite informação suficiente para entendermos por que está se comportando daquela forma?
Observabilidade é a capacidade de investigar o estado e o comportamento interno de um sistema a partir dos sinais que ele produz.
Ela se torna especialmente importante quando a causa do problema não foi prevista antecipadamente. Em vez de depender apenas de dashboards fixos para perguntas conhecidas, você precisa conseguir explorar o sistema e formular novas perguntas durante a investigação.
Observabilidade não é apenas “ter logs”
Logs são um sinal importante, mas não contam a história inteira.
Uma aplicação pode registrar cada erro e ainda ser difícil de diagnosticar se não houver correlação entre requisições, contexto do usuário, serviço envolvido e tempo da operação.
Da mesma forma, você pode ter centenas de métricas e ainda não saber por que um pedido específico levou oito segundos para terminar.
Observabilidade surge da combinação entre instrumentação, contexto e sinais úteis.
Uma forma simples de começar é pensar em três sinais muito comuns:
- logs;
- métricas;
- traces.
Eles não são uma lei universal nem o limite do tema. O próprio OpenTelemetry também trabalha com contexto propagado e outros sinais. Mas logs, métricas e traces formam um bom modelo inicial para quem está entrando em operação de sistemas.
Logs: eventos e contexto
Logs registram acontecimentos. Um serviço pode registrar que recebeu uma requisição, abriu uma conexão, processou um pagamento ou encontrou uma exceção.
O valor do log depende do contexto que acompanha a mensagem.
Compare:
erro ao salvar pedido
com:
order_id=93812 service=checkout operation=create_order duration_ms=1842 result=error
A segunda mensagem oferece mais pistas para investigação sem precisar adivinhar qual operação falhou.
Em sistemas distribuídos, logs ficam ainda mais úteis quando carregam identificadores que permitem correlacioná-los com uma requisição ou trace.
Mas registrar tudo indiscriminadamente também cria problemas: custo, ruído, dificuldade de busca e risco de vazar dados sensíveis.
Logs precisam ser deliberados. Tokens, senhas, dados pessoais e segredos não devem aparecer apenas porque “ajudariam no debug”.
Métricas: comportamento agregado ao longo do tempo
Métricas representam medidas numéricas capturadas durante a execução e geralmente agregadas ao longo do tempo.
Exemplos:
- requisições por segundo;
- taxa de erro;
- latência;
- uso de CPU;
- memória;
- profundidade de uma fila;
- quantidade de jobs concluídos;
- saturação de um recurso.
Elas são ótimas para enxergar tendência e mudança de comportamento.
Se a taxa de erro passa de 0,2% para 8% depois de um deploy, uma métrica torna esse desvio visível rapidamente. Mas ela não necessariamente explica qual requisição específica falhou nem por qual caminho ela passou.
Traces: o caminho de uma operação
Um trace acompanha uma operação enquanto ela atravessa componentes do sistema.
Imagine uma compra que percorre:
frontend
↓
API
↓
serviço de pedidos
↓
banco
↓
serviço de pagamento
↓
fila
Se a operação leva três segundos, o trace ajuda a mostrar onde esse tempo foi gasto.
Cada trecho da operação pode ser representado por um span. Juntos, esses spans formam a trajetória da requisição e carregam atributos úteis para análise.
Tracing é especialmente valioso em sistemas distribuídos, nos quais uma única ação do usuário atravessa vários serviços e dependências.
Sem correlação, você pode ter um log em cada serviço e ainda precisar reconstruir manualmente o caminho da operação.
Correlação transforma sinais isolados em investigação
O ganho aparece quando logs, métricas e traces deixam de ser ilhas.
Uma investigação pode começar por uma métrica:
a latência aumentou às 14:32
Depois você filtra traces daquele intervalo e encontra que chamadas para um serviço específico ficaram lentas. A partir do trace, abre os logs relacionados e encontra a condição que causou a degradação.
Esse fluxo é muito mais poderoso do que abrir arquivos de log aleatoriamente.
Observabilidade não exige que toda investigação siga exatamente essa ordem. O ponto é existir contexto suficiente para navegar entre sinais e formular novas perguntas.
Healthcheck responde uma pergunta mais estreita
Healthcheck é importante, mas ele não substitui observabilidade.
Um endpoint /health/ready pode responder se a aplicação está pronta para receber tráfego. Outro teste pode verificar se o processo está vivo. Esses sinais são úteis para automação e orquestração porque produzem respostas objetivas.
Mas um serviço pode estar healthy e ainda apresentar alta latência, erros específicos para uma rota, saturação de fila ou degradação em uma dependência externa.
Pense assim:
healthcheck
"esta capacidade mínima está disponível?"
observabilidade
"por que o sistema está se comportando assim?"
O artigo Docker Healthcheck: containers confiáveis com Compose mostra a aplicação prática dessa camada mais estreita de sinal.
Monitoramento e observabilidade não são exatamente sinônimos
Monitoramento costuma acompanhar condições e indicadores que você já decidiu observar: taxa de erro, uso de CPU, latência, espaço em disco, filas e disponibilidade.
Isso é essencial. O material de SRE do Google descreve monitoramento como coleta, processamento, agregação e exibição de dados quantitativos sobre o sistema.
Observabilidade amplia a capacidade de investigação. Ela precisa permitir perguntas que não estavam todas previstas quando os dashboards foram criados.
Uma comparação útil é:
monitoramento
"o erro passou do limite conhecido?"
observabilidade
"o que mudou, onde começou e quais operações foram afetadas?"
Na prática, os dois se complementam. Uma boa operação precisa tanto de indicadores conhecidos quanto de capacidade exploratória.
Também não existe uma fronteira universal aceita por todas as equipes e ferramentas. O vocabulário varia. O importante é entender a capacidade que você precisa, em vez de discutir apenas o nome usado pelo fornecedor.
Alertas transformam sinais em ação
Coletar telemetria não significa que alguém deva receber uma notificação para cada desvio.
Alertas são regras de ação. Eles deveriam chamar atenção quando existe algo que exige resposta humana ou automatizada.
Um bom alerta tenta responder:
- há impacto real ou risco relevante?
- alguém precisa agir agora?
- existe informação suficiente para começar a investigação?
- o alerta é acionável ou apenas informa ruído?
Alertar para cada pico de CPU pode gerar fadiga. Alertar para aumento sustentado de erros que afeta usuários é diferente.
Quanto mais ruído, maior a chance de um alerta importante ser ignorado.
OpenTelemetry é instrumentação, não “a observabilidade inteira”
OpenTelemetry é um projeto e ecossistema aberto para instrumentar aplicações e coletar, processar e exportar telemetria.
Ele oferece uma linguagem comum para sinais como traces, métricas e logs e ajuda a reduzir acoplamento direto com um único backend de observabilidade.
Isso é muito útil, mas instalar um SDK não torna automaticamente um sistema observável.
Você ainda precisa decidir:
- quais operações instrumentar;
- quais atributos ajudam no diagnóstico;
- como propagar contexto entre serviços;
- quais dados não podem ser coletados;
- como armazenar e consultar telemetria;
- quais métricas e alertas representam experiência real do usuário;
- quanto de volume e cardinalidade é sustentável.
Instrumentação ruim pode produzir muito dado e pouca informação.
Por isso, OpenTelemetry deve ser entendido como uma base técnica para produzir e transportar sinais, não como substituto de arquitetura operacional, dashboards, alertas, investigação e cultura de resposta a incidentes.
Mais dados também têm custo
Observabilidade não é maximizar volume de telemetria.
Logs, métricas e traces consomem processamento, rede, armazenamento e dinheiro. Alguns tipos de dado também podem criar risco de privacidade ou segurança.
Um atributo de alta cardinalidade usado sem cuidado pode aumentar muito o custo de uma plataforma de métricas. Capturar traces de 100% das requisições pode ser desnecessário em determinados sistemas. Registrar payloads inteiros pode expor informação que nunca deveria sair da aplicação.
O objetivo é preservar informação suficiente para responder perguntas relevantes com custo e risco aceitáveis.
Isso exige revisão contínua: que sinais realmente ajudam? O que ninguém consulta? O que falta quando ocorre um incidente?
Como observar seu próprio sistema agora
Você não precisa começar instalando uma plataforma enorme.
Escolha uma operação importante da sua aplicação — login, checkout, criação de pedido, geração de relatório — e tente responder:
- existe uma métrica que mostra volume, erro e latência dessa operação?
- um erro gera log com contexto suficiente para identificar a operação sem expor dados sensíveis?
- se a operação atravessa vários serviços, consigo acompanhar o caminho completo?
- existe um healthcheck que represente prontidão real para receber tráfego?
- um alerta importante aponta para informação útil ou apenas diz "algo falhou"?
- depois de um deploy, consigo comparar o comportamento antes e depois?
Cada resposta negativa é uma oportunidade concreta de melhorar observabilidade.
Uma abordagem boa começa pelo que você precisa investigar e só depois escolhe ferramentas.
Observabilidade fecha o ciclo da entrega
Nos conceitos anteriores desta jornada, a preocupação estava em integrar código, validar mudanças e fazer deploy de forma controlada.
Observabilidade acrescenta a etapa que confirma o que aconteceu no sistema real.
mudança
↓
CI/CD
↓
deploy
↓
healthcheck
↓
tráfego real
↓
logs + métricas + traces
↓
feedback
↺
Esse feedback retorna para desenvolvimento. Ele pode revelar uma regressão, uma hipótese errada, uma dependência lenta ou simplesmente um comportamento que ninguém havia previsto.
É por isso que observabilidade não pertence apenas a uma equipe de operações. Desenvolvedores precisam entender como o software será investigado depois que sair do ambiente local.
Código operável é código que deixa evidência suficiente para ser compreendido quando algo muda.
A partir daqui, os próximos aprofundamentos naturais são instrumentação com OpenTelemetry, alertas e SLOs, tracing distribuído e práticas de resposta a incidentes. Antes disso, dominar a diferença entre logs, métricas, traces, healthchecks e alertas já muda significativamente a forma como você constrói e opera software.
Infraestrutura saudável não garante experiência saudável
Um servidor pode estar com CPU em 25%, memória estável e disco sobrando enquanto usuários recebem erro ao finalizar uma compra.
Esse é um motivo para não limitar monitoramento a recursos de infraestrutura.
O livro de SRE do Google popularizou quatro sinais úteis para serviços voltados a usuários: latência, tráfego, erros e saturação. Eles não substituem o modelo completo de observabilidade, mas ajudam a evitar dashboards compostos apenas por CPU, RAM e disco.
O ponto é medir o sistema próximo da experiência que realmente importa.
Para uma API, isso pode significar taxa de sucesso e latência das requisições. Para um worker, idade da mensagem mais antiga e profundidade da fila. Para um checkout, talvez seja necessário acompanhar se a operação conclui corretamente, e não apenas se a aplicação responde HTTP.
Essa mudança de perspectiva é importante porque confiabilidade não significa somente “o processo está de pé”. Significa o serviço entregar o comportamento esperado pelos usuários.
Instrumentação precisa existir antes da pergunta difícil
Durante um incidente, é comum perceber tarde demais que faltava justamente o dado necessário para confirmar uma hipótese.
Talvez você descubra que os logs não carregam um identificador de correlação. Ou que não existe métrica por operação. Ou que o trace termina antes de uma dependência importante. Nesse momento, adicionar instrumentação pode ajudar o próximo incidente, mas não recria o passado perdido.
Por isso, observabilidade também é uma decisão de design.
Ao implementar uma funcionalidade, vale perguntar:
- como saberemos que ela está funcionando?
- como saberemos que está lenta?
- como distinguiremos erro do usuário de erro do sistema?
- qual contexto precisaremos para reproduzir ou investigar uma falha?
- quais dados são sensíveis e devem ser excluídos ou mascarados?
Essas perguntas aproximam desenvolvimento e operação. Em vez de “colocar logs depois”, a capacidade de diagnosticar passa a fazer parte da definição de software pronto para produção.
Uma resposta