layout: post title: “Observabilidade de verdade: logs, métricas e tracing sem ilusão” date: 2026-03-06 categories: [cloud, devops, monitoramento] tags: [observabilidade, logs, metricas, tracing, azure] author: “WRPD” —

Introdução

Todo sistema “funciona bem”… até parar.

E quando para, surge a pergunta que separa ambientes maduros de ambientes frágeis:

Você consegue entender rapidamente o que aconteceu?

Observabilidade não é ter logs.
Não é ter dashboard bonito.
É conseguir diagnosticar problema sem adivinhação.

O erro mais comum

Muita gente acha que tem observabilidade porque:

• Tem logs
• Tem um gráfico de CPU
• Tem um alerta genérico

Na prática:

• Logs não dizem nada útil
• Métricas não explicam causa
• Alertas chegam tarde ou sem contexto

Os três pilares

Observabilidade de verdade se apoia em três pilares:

1. Logs

Eventos detalhados do sistema.

Exemplo:

• Erros de aplicação
• Requests HTTP
• Falhas de autenticação

2. Métricas

Indicadores numéricos ao longo do tempo.

Exemplo:

• CPU
• Memória
• Latência
• Taxa de erro

3. Tracing

Fluxo completo de uma requisição.

Exemplo:

• API → serviço → banco → resposta

Onde a maioria erra

Logs sem padrão

• Mensagens inconsistentes
• Sem contexto
• Difícil de buscar

Métricas isoladas

• CPU alta… mas por quê?
• Memória subindo… qual processo?

Falta de correlação

• Não dá para ligar um erro a uma requisição
• Não dá para rastrear o problema ponta a ponta

O que é observabilidade de verdade

Você tem observabilidade quando consegue responder:

• O que falhou?
• Quando começou?
• Qual impacto?
• Qual a causa provável?

Sem isso, você só tem dados — não visibilidade.

Um exemplo real

Cenário:

• Usuário reclama que o sistema está lento

Sem observabilidade:

• “Aqui está normal”
• Tentativa e erro
• Reinício como solução padrão

Com observabilidade:

• Métrica mostra aumento de latência
• Logs indicam timeout no banco
• Tracing mostra query lenta específica

Problema identificado em minutos.

O papel dos logs

Logs precisam ser:

Estruturados

Evitar:

Erro ao processar requisição

Preferir:

{
  "level": "error",
  "message": "Erro ao processar requisição",
  "endpoint": "/api/tickets",
  "user_id": 123,
  "trace_id": "abc123"
}

Contextualizados

Sempre incluir:

• ID da requisição
• Usuário (quando aplicável)
• Serviço

Métricas que realmente importam

Nem toda métrica é útil.

As principais:

• Latência (tempo de resposta)
• Taxa de erro
• Throughput (requisições por segundo)
• Uso de recursos (CPU/memória)

Tracing: o nível que poucos implementam

Tracing conecta tudo.

Sem ele:

• Você vê sintomas

Com ele:

• Você vê a causa

Ferramentas comuns:

• OpenTelemetry
• Jaeger
• Azure Application Insights

O caso real: Azure Container Apps

No ACA, o básico inclui:

• Logs via Log Analytics
• Métricas da aplicação
• Integração com Application Insights

Mas o erro comum é:

• Usar só logs de console
• Não estruturar dados
• Não correlacionar eventos

Alertas que funcionam

Outro ponto crítico:

Alertas ruins:

• “CPU alta”
• “Erro genérico”

Alertas bons:

• “Taxa de erro > 5% nos últimos 5 minutos”
• “Latência acima de X ms para endpoint crítico”

Um padrão saudável

Uma stack simples e eficiente:

• Logs estruturados (JSON)
• Métricas bem definidas
• Tracing implementado
• Alertas baseados em impacto

Checklist rápido

• Logs têm padrão?
• É possível buscar por requisição?
• Métricas refletem experiência do usuário?
• Existe tracing ponta a ponta?
• Alertas ajudam ou só fazem barulho?

Conclusão

Observabilidade não é ferramenta — é capacidade.

E essa capacidade define quanto tempo você leva para sair de:

“Algo está errado”

para:

“Sabemos exatamente o que aconteceu”