Observabilidade é a forma de entender o estado de um sistema a partir do que ele produz. Com sinais, indicadores e alertas bem definidos, a equipe pode investigar uma falha antes que o cliente precise apontá-la.

Observabilidade começa pela perspectiva do usuário

Monitoramento costuma responder se uma condição conhecida está acontecendo. Observabilidade amplia a pergunta: com os dados produzidos pelo sistema, conseguimos entendê-lo externamente e investigar também problemas que ainda não foram previstos?

A instrumentação deve emitir traces, métricas e logs. Um trace acompanha o caminho de uma operação; uma métrica resume o comportamento ao longo do tempo; um log registra eventos e contexto. Já o SLI mede o serviço pela perspectiva do usuário. Em uma busca, por exemplo, pode representar a proporção de consultas concluídas ou a latência percebida.

Traces, métricas e logs explicam partes diferentes

  • Métricas mostram tendências, como aumento de latência ou queda de operações concluídas.
  • Traces mostram onde uma requisição gastou tempo e quais serviços participaram do fluxo.
  • Logs registram erros, eventos e detalhes úteis para entender o contexto de uma ocorrência.

Imagine que a busca fique lenta. A métrica sinaliza a mudança; o trace pode apontar a consulta SQL ou o serviço que concentrou o tempo; o log pode registrar a falha e o contexto necessário para reproduzi-la. Sem essa combinação, a equipe sabe que há lentidão, mas demora mais para localizar a causa.

Alertas devem apontar impacto, não apenas ruído

Alertar para cada erro não é observabilidade; é ruído. Um alerta deve representar uma condição que merece investigação ou ação, de preferência ligada a um objetivo de nível de serviço, o SLO.

O uso de burn rates em múltiplas janelas ajuda a equilibrar tempo de detecção, precisão e prioridade. Uma janela mais sensível pode sinalizar uma degradação rápida; outra ajuda a evitar reação a um evento breve. A escolha depende do impacto que o produto aceita e da resposta que a equipe consegue executar.

Tráfego sintético acrescenta outra perspectiva: um fluxo controlado pode testar login, consulta ou outra operação segura em intervalos regulares. Se ele encontrar erro ou latência enquanto o tráfego real ainda parece normal, a equipe ganha um sinal para investigar antes de afetar muitos usuários.

Como transformar um alerta em ação

No Prometheus, uma regra de alerta avalia uma expressão sobre séries temporais. A cláusula for exige que a condição persista antes de o alerta disparar; anotações podem levar descrição, contexto e link para um runbook.

  • Escolha o SLI que representa o comportamento percebido pelo cliente, em vez de uma variável isolada sem impacto conhecido.
  • Defina a expressão e o limiar a partir do SLO acordado para o serviço.
  • Ajuste a persistência da condição ao risco: eventos transitórios não devem gerar ação sem contexto, enquanto falhas críticas exigem uma regra compatível com a urgência.
  • Inclua nas anotações o que aconteceu, a equipe responsável e o link do runbook com verificações iniciais e caminhos de correção.

O fluxo fica mais útil quando cada sinal conduz a uma próxima decisão: investigar, comunicar, mitigar ou corrigir. O painel mostra o estado; o alerta organiza a prioridade; o runbook orienta o primeiro passo.

Se o suporte costuma descobrir falhas antes da equipe técnica, converse com a LYPES sobre o gargalo atual do produto. Podemos discutir quais sinais, alertas e melhorias de instrumentação fazem sentido para a operação real e priorizar a evolução com responsabilidade.