Observabilidade não é uma ferramenta que se compra, é uma capacidade que se constrói: entender o estado de um sistema pelo lado de fora, sem precisar acessar o servidor e adivinhar. Um sistema observável permite que a equipe descubra um problema antes do cliente, entenda a causa rápido e saiba se a correção funcionou.

Três tipos de sinal se complementam — logs, métricas e traces. Cada um responde a um tipo de pergunta diferente. Este artigo explica os três sem jargão e mostra por onde uma equipe deve começar.

Logs — o que aconteceu com esta requisição

Logs são registros de eventos, com data, hora e contexto: “às 14h32, o usuário X tentou pagar e o gateway respondeu com erro Y”. São a ferramenta para investigar um caso específico — um cliente que reclama, um pedido que falhou, um comportamento estranho relatado.

O que torna logs úteis: serem estruturados (campos identificáveis, não texto livre), carregarem um identificador que permita seguir uma requisição por vários sistemas, e terem um nível de detalhe adequado — nem tão pouco que não sirva para nada, nem tanto que o custo de armazenamento exploda e a informação relevante se perca no ruído.

O ponto fraco dos logs é o volume: guardar tudo, para sempre, é caro. A prática é reter os logs recentes com detalhe e os antigos de forma resumida ou agregada.

Métricas — como o sistema está se comportando

Métricas são números agregados ao longo do tempo: requisições por segundo, tempo de resposta médio e nos piores casos, taxa de erro, uso de CPU e memória, tamanho de fila. Respondem a perguntas de tendência: “o sistema está mais lento hoje do que ontem?”, “a taxa de erro subiu depois do último deploy?”, “estamos perto do limite de capacidade?”.

Métricas são baratas de guardar (são só números) e ideais para dashboards e alertas. O que elas não fazem é explicar um caso individual — para isso, você volta aos logs ou aos traces.

As métricas mais valiosas para começar são as que refletem a experiência do usuário: disponibilidade, latência e taxa de erro dos fluxos principais. A partir delas, você adiciona métricas de recursos e de negócio conforme a necessidade.

Traces — onde está a lentidão

Um trace mostra o caminho completo de uma requisição pelos vários serviços que ela toca, com o tempo gasto em cada etapa: 20 ms no serviço de autenticação, 300 ms no banco, 150 ms numa chamada a um sistema externo. Responde à pergunta “por que esta requisição demorou dois segundos?” em arquiteturas com muitas partes.

Traces são especialmente úteis quando o sistema é distribuído — vários serviços, filas, chamadas a terceiros. Em um sistema simples, um bom log com marcação de tempo já dá boa parte da informação.

Como os três trabalham juntos

Um fluxo típico de investigação: uma métrica alerta que a latência do checkout subiu. Você olha os traces das requisições lentas e vê que o tempo extra está numa chamada ao serviço de estoque. Você abre os logs desse serviço no período e descobre que ele está reprocessando uma fila acumulada. Três sinais, três perguntas, uma causa.

Um quarto pilar: eventos e mudanças

Além de logs, métricas e traces, é muito útil registrar as mudanças no sistema — deploys, alterações de configuração, mudanças de infraestrutura — na mesma linha do tempo das métricas. A pergunta “o que mudou pouco antes de o problema começar?” é a mais eficiente em uma investigação, e ela só se responde se as mudanças estiverem marcadas junto com os gráficos. Um simples marcador de “deploy da versão X às 14h” sobre o gráfico de erros economiza horas.

Cardinalidade: o que faz a conta de métricas explodir

Um detalhe técnico com impacto de custo grande: cada combinação distinta de rótulos em uma métrica cria uma série temporal separada. Adicionar um rótulo com o ID do usuário, ou a URL completa, a uma métrica de alto volume pode gerar milhões de séries e uma conta enorme. A regra é usar rótulos de baixa cardinalidade — status, endpoint, região — e deixar o detalhe individual para os logs e traces.

Por onde começar

Equipes costumam achar que precisam de uma plataforma completa antes de ter qualquer observabilidade. Não é o caso. Uma ordem realista:

  1. Alertas de erro — capturar exceções da aplicação e ser notificado quando algo quebra. Isso sozinho já muda o jogo: o time sabe do problema antes do cliente.
  2. Métricas dos quatro sinais de ouro — latência, tráfego, erros e saturação — dos fluxos principais.
  3. Logs estruturados com um identificador de requisição.
  4. Um dashboard simples que a equipe realmente olha.
  5. Traces, quando a arquitetura for distribuída o suficiente para justificar.

O que evitar

  • Alerta demais — quando tudo alerta, ninguém liga. Alertas devem ser acionáveis e raros; o resto é dashboard.
  • Dashboards que ninguém abre — cem gráficos bonitos sem dono não são observabilidade.
  • Logar dados sensíveis — senhas, cartões, dados pessoais em log são um risco de segurança e de conformidade.
  • Métrica sem alvo — um número só é útil se você sabe qual valor é bom e qual é ruim.
  • Comprar a ferramenta antes de saber o que medir — a prática vem antes da plataforma.

Os quatro sinais de ouro

Uma referência prática, popularizada pela engenharia de confiabilidade do Google, define quatro métricas que, monitoradas, cobrem a maior parte dos problemas de um serviço:

  • Latência — quanto tempo as requisições levam, separando as bem-sucedidas das que falham.
  • Tráfego — quanta demanda o serviço está recebendo.
  • Erros — a taxa de requisições que falham.
  • Saturação — o quão “cheio” está o recurso mais limitado (CPU, memória, conexões, fila).

Começar por esses quatro, nos fluxos que mais importam para o negócio, entrega mais do que dezenas de métricas de infraestrutura soltas.

Alertas que funcionam

Um alerta só é bom se três coisas forem verdade: ele indica um problema real (não um falso positivo), é acionável (há algo a fazer) e chega a quem pode agir. Alertas que não cumprem isso treinam a equipe a ignorá-los — e no dia do problema de verdade, o alerta importante se perde no meio do ruído.

A prática recomendada é alertar sobre sintomas que o usuário sente (o checkout está lento, a taxa de erro subiu), não sobre causas intermediárias (a CPU está em 80%). Uma CPU alta pode ser normal; um checkout lento nunca é.

Observabilidade em quem não tem time de plantão

Empresas menores costumam achar que observabilidade é coisa de operação 24 horas. Não é. Mesmo sem plantão, saber que algo quebrou às 3h da manhã — e ter o contexto para resolver às 8h — é muito melhor do que descobrir pelo cliente ao meio-dia. E boa parte dos problemas, uma vez visíveis, se resolve de forma automática ou com uma ação simples que pode esperar o horário comercial.

SLIs, SLOs e a linguagem de confiabilidade

Alguns termos ajudam a alinhar a conversa entre negócio e tecnologia. Um SLI (indicador de nível de serviço) é uma métrica concreta — por exemplo, “percentual de requisições respondidas em menos de 300 ms”. Um SLO (objetivo de nível de serviço) é a meta para esse indicador — “99% em menos de 300 ms”. O SLA é o compromisso contratual, geralmente menos rigoroso que o SLO interno.

Definir dois ou três SLOs para os fluxos mais importantes dá à equipe um alvo claro e à liderança uma forma objetiva de saber se o sistema está saudável, sem depender de sensação.

Dashboards: menos é mais

O instinto ao montar observabilidade é criar um dashboard para tudo. O resultado costuma ser dezenas de painéis que ninguém abre. O mais útil é ter um painel principal — poucos gráficos, os que respondem “o sistema está bem agora?” — que fica visível para a equipe, e painéis específicos que são consultados só durante uma investigação. Cada painel deve ter um dono e um propósito claro.

Observabilidade e custo

Guardar todos os logs de tudo, para sempre, com indexação completa, é caro — às vezes tão caro quanto a própria infraestrutura da aplicação. O equilíbrio está em reter com detalhe o que é recente e provável de ser consultado, amostrar o que é volumoso e de baixo valor individual, e agregar o histórico. Definir essa política é parte do trabalho.

Como a Jumps trata

A Jumps configura observabilidade como parte de infraestrutura, começando pelo essencial — alertas de erro e métricas dos fluxos críticos — e evoluindo conforme o sistema. Em sustentação e evolução, esses sinais são acompanhados de forma contínua, e é por eles que a maioria dos problemas é resolvida antes de virar incidente.

Se o seu sistema está no ar sem visibilidade do que acontece nele, fale com a Jumps.