O que é observabilidade e por que monitorar não basta

Quase toda empresa tem monitoramento. Painéis com CPU, memória, disco, alguns alertas configurados, talvez um teste que verifica se o site responde. E quase toda empresa, em algum incidente, viveu a mesma cena: todos os gráficos verdes, nenhum alerta disparado, e o cliente ligando para dizer que o sistema está lento.

Essa cena é a diferença entre monitoramento e observabilidade, e ela custa horas de investigação às cegas.

A diferença, sem jargão

Monitoramento acompanha indicadores que você escolheu de antemão e avisa quando saem da faixa esperada. Responde a pergunta: "está tudo bem?"

Observabilidade é conseguir entender o que está acontecendo por dentro do sistema a partir do que ele emite — inclusive para perguntas que você não previu. Responde: "por que está assim?"

A distinção prática está nas perguntas que cada um atende:

Repare: monitoramento acerta as duas primeiras e não ajuda nas outras cinco. E são justamente as cinco que você precisa responder durante um incidente real.

Por que monitorar recurso não basta

A raiz do problema é que uso de recurso não descreve experiência do usuário.

Um sistema pode estar com CPU em 30% e memória folgada, e mesmo assim:

• Esperar por um banco de dados lento.
• Esperar por uma API de terceiro que degradou.
• Estar estrangulado por um limite de recurso configurado baixo demais — ficando lento sem aparecer consumo alto.
• Ter uma fila crescendo sem ninguém consumir.
• Falhar para 5% das requisições, o que não move nenhuma média.

Esse último ponto merece ênfase: média esconde. Um tempo de resposta médio de 200 ms pode conter 5% das requisições levando 8 segundos. Para quem está nesses 5%, o sistema está quebrado, e o painel está verde.

Por isso a mudança mais barata e de maior impacto em qualquer monitoramento existente é parar de olhar média e passar a olhar percentis — o percentil 95 e o 99 mostram a experiência de quem está sendo mal atendido.

Os três sinais

Observabilidade se apoia em três tipos de dado, com propósitos diferentes:

Métricas

Números ao longo do tempo: requisições por segundo, taxa de erro, latência, uso de recurso, tamanho de fila.

Boas para: gráfico, alerta e tendência. São baratas de guardar por muito tempo, o que permite comparar hoje com o mês passado.

Limitadas em: detalhe. A métrica diz que a taxa de erro subiu; não diz qual erro, nem para quem.

Logs

Registro de eventos, com contexto: o que aconteceu, quando, com quais dados.

Bons para: investigar um caso específico, entender a sequência, ver a mensagem de erro real.

Limitados em: volume e custo. Log é caro de guardar e de pesquisar. E — o ponto crítico — log que só existe dentro do servidor ou do container não existe: ele some junto com o que você precisa investigar.

Traces (rastreamento)

O caminho de uma requisição atravessando os vários serviços, mostrando quanto tempo foi gasto em cada etapa.

Bons para: responder "onde o tempo foi?" em arquitetura distribuída. É o sinal que falta na maioria dos ambientes e o que mais acelera diagnóstico quando existe.

Limitados em: esforço de instrumentação. Exige que as aplicações propaguem o contexto da requisição entre si.

Os três se complementam: a métrica avisa que algo mudou, o trace mostra onde, o log explica o quê.

O que de fato muda na operação

Quando os três existem e estão centralizados:

• O diagnóstico deixa de ser por eliminação. Em vez de conectar em cada servidor procurando pistas, você parte do sintoma e chega na causa.
• O tempo de recuperação cai, que é o indicador que o negócio sente.
• Problema intermitente vira investigável. Aquele erro que acontece duas vezes por semana e ninguém consegue reproduzir passa a ter rastro.
• Decisão de capacidade passa a ter base. Tendência em vez de impressão.
• Deploy fica menos assustador, porque dá para comparar o antes e o depois com números.

O que medir primeiro

Se o ambiente não tem quase nada, comece pelo que descreve a experiência do usuário, não pelo que descreve o servidor. Quatro sinais cobrem a maior parte:

1. Taxa de requisições — quanto tráfego está chegando.
2. Taxa de erro — que percentual falha.
3. Latência em percentis altos — como está sendo atendido quem está pior.
4. Saturação — o quanto o recurso mais escasso está perto do limite.

E, para cargas assíncronas, acrescente o tamanho e a idade da fila, que costuma ser o primeiro sinal de que algo parou.

Depois disso, uma métrica de negócio: pedidos por minuto, logins bem-sucedidos, transações concluídas. Ela é a que detecta o problema que nenhum indicador técnico pegou — e a que convence a diretoria de que o investimento valeu.

Alerta: menos é mais

A parte que mais se erra depois de implantar. Alertar demais produz ruído, e ruído treina a equipe a ignorar — de modo que, no dia importante, o alerta real passa despercebido.

Três regras que sustentam a confiança no sistema de alerta:

• Alerta precisa ter ação definida. Se quem recebe não sabe o que fazer, não deveria ter sido acordado.
• Alerte sobre sintoma, não sobre causa. "A taxa de erro do checkout subiu" é acionável. "A CPU do servidor 3 está em 85%" talvez não seja nada.
• Se não exige ação imediata, não acorda ninguém. Vira tarefa no horário comercial.

Um teste honesto: quantos alertas o seu time recebeu no último mês, e quantos exigiram ação? Se a proporção for baixa, o problema não é falta de monitoramento — é excesso de ruído.

Erros comuns

• Monitorar só recurso de servidor, sem nenhum indicador de experiência do usuário.
• Olhar média em vez de percentil, e não enxergar quem está mal atendido.
• Log apenas local, perdido junto com o container ou o servidor investigado.
• Nenhum rastreamento em arquitetura distribuída, diagnosticando por eliminação.
• Alertar sobre tudo, e treinar a equipe a ignorar.
• Alerta sem ação definida.
• Relógio dessincronizado entre máquinas, inviabilizando correlacionar.
• Retenção curta demais para investigar problema descoberto semanas depois.
• Painel bonito que ninguém abre, sem alerta que chegue a alguém.
• Comprar ferramenta antes de definir o que precisa ser respondido.

Por onde começar, na ordem

1. Log centralizado, fora das máquinas, com retenção definida. É o passo de maior retorno imediato.
2. Métricas dos quatro sinais de experiência do usuário, com histórico.
3. Alertas poucos e acionáveis, com destino e procedimento definidos.
4. Uma métrica de negócio no painel, ao lado das técnicas.
5. Rastreamento, quando houver mais de um serviço no caminho da requisição.
6. Revisão periódica dos alertas: o que disparou, o que exigiu ação, o que virou ruído.

Fazer o passo 5 antes do 1 é comum e improdutivo — rastreamento sofisticado sem log centralizado deixa o diagnóstico incompleto.

Onde a Solvefy/Cloud entra

Implantamos observabilidade na ordem que entrega resultado: log centralizado e estruturado, métricas de experiência do usuário com percentis em vez de média, alertas poucos e acionáveis com procedimento escrito, métrica de negócio no painel e rastreamento onde a arquitetura justifica. Trabalhamos com a stack open source — Prometheus, Grafana, Loki, Jaeger — ou com a ferramenta que você já tem. E revisamos os alertas existentes, porque cortar ruído costuma ser tão valioso quanto adicionar sinal.

Seu painel está verde enquanto o cliente reclama? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.