Observabilidade: Os Três Pilares para Monitorar Aplicações Modernas

Em um mundo onde sistemas distribuídos e microserviços são cada vez mais comuns, simplesmente “monitorar” não é mais suficiente. Você precisa de observabilidade - a capacidade de entender o que está acontecendo dentro do seu sistema baseado apenas em suas saídas externas.

Neste artigo, vamos explorar os fundamentos da observabilidade moderna e como ela pode transformar a forma como você desenvolve e mantém aplicações.

O Que é Observabilidade?

Observabilidade é a capacidade de inferir o estado interno de um sistema baseado no conhecimento de suas saídas externas. Em termos práticos, é responder perguntas como:

  • 🔍 Por que aquela requisição específica falhou?
  • ⏱️ Qual serviço está causando lentidão na aplicação?
  • 💾 Qual o consumo real de recursos do meu sistema?
  • 🐛 Como reproduzir um bug que só acontece em produção?

Monitoramento vs Observabilidade

Monitoramento tradicional:

  • Você define o que monitorar antecipadamente
  • Funciona para problemas conhecidos
  • Dashboards com métricas pré-definidas
  • “Está funcionando ou não?”

Observabilidade:

  • Você descobre o que investigar depois que o problema acontece
  • Funciona para problemas desconhecidos
  • Exploração livre de dados
  • “Por que não está funcionando?”

A observabilidade inclui monitoramento, mas vai muito além.

Os Três Pilares da Observabilidade

A observabilidade se baseia em três tipos fundamentais de telemetria:

1️⃣ Métricas - “O Que Está Acontecendo?”

Métricas são números agregados que mudam ao longo do tempo. Exemplos:

  • Requisições por segundo (throughput)
  • Latência média ou percentis (P50, P95, P99)
  • Taxa de erros (error rate)
  • Uso de CPU e memória
  • Tamanho de filas

Quando usar:

  • ✅ Monitoramento em tempo real
  • ✅ Alertas automáticos
  • ✅ Identificação de tendências
  • ✅ Dashboards operacionais

Exemplo de query (PromQL):

# Taxa de requisições HTTP por segundo
rate(http_requests_total[5m])

# Latência P95 em segundos
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

2️⃣ Logs - “Por Que Aconteceu?”

Logs são eventos textuais que descrevem o que aconteceu em um momento específico:

  • Requisições HTTP (método, path, status, duração)
  • Erros e exceções com stack traces
  • Eventos de negócio (usuário criado, pedido finalizado)
  • Mensagens de debug

Quando usar:

  • ✅ Investigação de problemas específicos
  • ✅ Auditoria e compliance
  • ✅ Análise de comportamento
  • ✅ Debugging de produção

Exemplo de query (LogQL):

# Buscar erros em um serviço específico
{service="api", level="error"}

# Taxa de logs de erro por minuto
rate({service="api", level="error"}[1m])

3️⃣ Traces - “Onde Está o Problema?”

Traces (ou rastreamento distribuído) mostram o caminho completo de uma requisição através de múltiplos serviços:

  • Visualização de chamadas entre serviços
  • Latência de cada etapa (spans)
  • Identificação de gargalos
  • Propagação de contexto

Quando usar:

  • ✅ Debugging de microserviços
  • ✅ Análise de performance
  • ✅ Identificação de dependências
  • ✅ Otimização de latência

Exemplo de span:

1
2
3
4
5
6
7

Request: GET /api/orders/123
├─ API Gateway (5ms)
├─ Auth Service (15ms)
├─ Orders Service (45ms)
│  ├─ Database Query (30ms) ← GARGALO!
│  └─ Cache Check (5ms)
└─ Total: 65ms

Como os Três Pilares Trabalham Juntos

A verdadeira poder da observabilidade está na correlação entre os três pilares:

Cenário Real: Investigando Latência Alta

1. Métricas detectam o problema:

1

Alerta: P95 de latência subiu de 100ms para 2s

2. Logs mostram contexto:

1
2

[ERROR] Database connection timeout após 30s
[ERROR] Retry tentativa 3/3 falhou

3. Traces identificam a causa raiz:

1
2
3
4

Requisição levou 2.1s total:
├─ API: 50ms
├─ Database: 2000ms ← PROBLEMA!
└─ Cache: 5ms

Conclusão: O banco de dados está sobrecarregado. Solução: adicionar índice ou escalar o DB.

Ferramentas Modernas de Observabilidade

Stack Open-Source (Grafana Stack)

Prometheus:

  • Coleta e armazena métricas
  • Time-series database otimizado
  • Pull-based (scraping)
  • PromQL para queries

Loki:

  • Agregação de logs
  • Indexação apenas de labels (eficiente)
  • LogQL similar ao PromQL
  • Integração nativa com Grafana

Tempo:

  • Rastreamento distribuído
  • Armazena traces completos
  • Integração com OpenTelemetry
  • Visualização de spans

Grafana:

  • Visualização e dashboards
  • Suporta múltiplas fontes de dados
  • Alertas integrados
  • Exploração de dados

Padrões da Indústria

OpenTelemetry:

  • Padrão unificado para instrumentação
  • Suporta métricas, logs e traces
  • Independente de vendor
  • SDKs para todas as linguagens principais
  • Substitui projetos legados (Jaeger, Zipkin, etc.)

Métricas Essenciais: The Four Golden Signals

O Google SRE define 4 métricas fundamentais que toda aplicação deve monitorar:

1. Latência (Latency)

Tempo que leva para processar uma requisição.

# P50, P95, P99
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

2. Tráfego (Traffic)

Quantidade de demanda no sistema.

# Requisições por segundo
sum(rate(http_requests_total[5m]))

3. Erros (Errors)

Taxa de requisições que falharam.

# Taxa de erro (%)
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m])) * 100

4. Saturação (Saturation)

Quão “cheio” está o serviço (CPU, memória, disco, etc.).

# Uso de CPU
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Boas Práticas de Observabilidade

1. Instrumentação desde o Início

❌ Não faça:

1
2
3
4
5

# Sem nenhuma observabilidade
def process_order(order_id):
    order = db.get_order(order_id)
    payment = process_payment(order)
    return order

✅ Faça:

1
2
3
4
5
6
7
8
9
10
11

# Com métricas, logs e traces
@tracer.start_as_current_span("process_order")
def process_order(order_id):
    logger.info(f"Processing order {order_id}")
    orders_counter.add(1)

    order = db.get_order(order_id)
    payment = process_payment(order)

    logger.info(f"Order {order_id} processed successfully")
    return order

2. Logging Estruturado

❌ Logs não estruturados:

1

Order 123 processed in 45ms by user john@email.com

✅ Logs estruturados (JSON):

1
2
3
4
5
6
7
8
9

{
  "timestamp": "2026-02-08T10:30:00Z",
  "level": "info",
  "message": "Order processed",
  "order_id": "123",
  "duration_ms": 45,
  "user_email": "john@email.com",
  "trace_id": "abc123"
}

Benefícios:

  • ✅ Fácil de parsear e filtrar
  • ✅ Correlação com traces via trace_id
  • ✅ Queries eficientes no Loki
  • ✅ Análise automatizada

3. Correlation IDs

Propague um ID único por toda a requisição:

1
2
3
4
5
6

Request ID: abc-123

[Service A] [abc-123] Received request
[Service B] [abc-123] Calling database
[Service B] [abc-123] Database query took 50ms
[Service A] [abc-123] Request completed

Isso permite rastrear uma requisição através de todos os logs e traces.

4. Métricas de Negócio

Não monitore apenas métricas técnicas. Monitore KPIs de negócio:

# Técnicas
http_requests_total
database_queries_duration_seconds

# Negócio
orders_completed_total
revenue_generated_dollars
user_signups_total
cart_abandonment_rate

5. Alertas Inteligentes

❌ Alert Fatigue:

1
2
3

🔔 CPU > 70% (alerta a cada 5 minutos)
🔔 Memória > 80%
🔔 Disco > 85%

✅ Alertas Significativos:

1
2
3

🚨 P95 latency > 1s por mais de 5 minutos
🚨 Error rate > 5% por mais de 2 minutos
🚨 SLO breach: 99.9% uptime em risco

SLIs, SLOs e SLAs

SLI (Service Level Indicator)

Métrica que indica a qualidade do serviço.

Exemplos:

  • Latência P95 < 200ms
  • Disponibilidade > 99.9%
  • Taxa de erro < 0.1%

SLO (Service Level Objective)

Target interno que você quer atingir.

1

SLO: 99.9% das requisições devem ter latência < 200ms

SLA (Service Level Agreement)

Contrato com o cliente, com penalidades se não atingido.

1

SLA: Garantimos 99.9% de uptime, ou você recebe crédito

Error Budget

Se seu SLO é 99.9% de uptime, você tem 0.1% de downtime permitido por mês:

1
2
3
4

30 dias = 43.200 minutos
0.1% = 43,2 minutos de downtime permitido

Error Budget Restante: 30 minutos

Quando o error budget acaba, você para de fazer deploys e foca em confiabilidade.

Aprenda na Prática

Para ajudar você a colocar esses conceitos em prática, criamos um laboratório completo de observabilidade que demonstra todos os três pilares em ação:

🔗 Lab de Observabilidade no GitHub

O laboratório inclui:

  • ✅ Stack completa Grafana (Prometheus + Loki + Grafana + Alloy)
  • ✅ Aplicações instrumentadas em múltiplas linguagens (.NET, Python, Java, TypeScript)
  • ✅ 10 dashboards pré-configurados
  • ✅ Métricas de host (Linux/WSL e Windows)
  • ✅ Exemplos práticos de queries PromQL e LogQL
  • ✅ Docker Compose para executar tudo localmente
  • ✅ Documentação completa

Basta clonar o repositório e executar:

1
2
3
4
5

git clone https://github.com/ferronicardoso/lab-observabilidade
cd lab-observabilidade
docker compose up -d

# Acessar Grafana: http://localhost:3000 (admin/admin)

Implementação Prática

Passo 1: Escolha suas Ferramentas

Open-Source (Recomendado para aprendizado):

  • Prometheus + Loki + Tempo + Grafana
  • OpenTelemetry para instrumentação

Soluções Comerciais:

  • Datadog
  • New Relic
  • Dynatrace
  • Elastic APM

Passo 2: Instrumente sua Aplicação

O OpenTelemetry oferece SDKs para todas as linguagens principais. O conceito é sempre o mesmo:

  1. Instalar SDK na sua linguagem
  2. Configurar exporters (Prometheus, OTLP, etc.)
  3. Instrumentação automática (HTTP, database, etc.)
  4. Métricas customizadas para regras de negócio

Instrumentação básica:

1
2
3
4
5

1. Adicionar bibliotecas OpenTelemetry
2. Configurar tracer e meter
3. Expor endpoint de métricas (/metrics)
4. Adicionar logging estruturado
5. Configurar Prometheus para fazer scrape

Passo 3: Configure Dashboards

Dashboard básico deve ter:

  • 📊 Golden Signals: Latência, Tráfego, Erros, Saturação
  • 📈 Métricas de Negócio: Conversões, receita, usuários ativos
  • 🚨 Alertas: Status de SLOs, error budget
  • 📝 Logs: Stream em tempo real de erros

Passo 4: Defina Alertas

1
2
3
4
5
6
7
8
9
10
11
12

# Exemplo de regra de alerta (Prometheus)
groups:
  - name: api_alerts
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        annotations:
          summary: "Taxa de erro acima de 5%"

Benefícios da Observabilidade

Para Desenvolvedores

  • ✅ Debugar produção sem reproduzir localmente
  • ✅ Entender performance de APIs
  • ✅ Validar otimizações com dados reais

Para SREs

  • ✅ Responder incidentes mais rápido
  • ✅ Prevenir problemas com alertas
  • ✅ Capacity planning baseado em dados

Para o Negócio

  • ✅ Menos downtime = mais receita
  • ✅ Melhor experiência do usuário
  • ✅ Decisões baseadas em dados

Conclusão

Observabilidade não é um luxo - é uma necessidade em sistemas modernos. Os três pilares (métricas, logs, traces) trabalham juntos para dar visibilidade completa do seu sistema.

Principais takeaways:

  1. 📊 Métricas detectam problemas
  2. 📝 Logs explicam o contexto
  3. 🔍 Traces mostram onde está o gargalo
  4. 🎯 Use SLOs para medir qualidade
  5. 🛠️ OpenTelemetry é o padrão moderno
  6. 📈 Golden Signals são essenciais
  7. 🚨 Alertas devem ser significativos

Próximos Passos:

  • Estude OpenTelemetry na sua linguagem
  • Experimente Prometheus + Grafana localmente
  • Implemente logging estruturado nos seus projetos
  • Defina SLOs para seus serviços críticos

Referências:

Observabilidade é uma jornada contínua. Comece simples, itere e melhore. Seus sistemas (e sua equipe) vão agradecer!

Happy Observing! 🔍📊