Observabilidade: enxergando o comportamento do sistema

Performance não é sobre intuição — é sobre dados. Sem visibilidade clara do comportamento do sistema, otimização vira adivinhação. Observabilidade é a capacidade de entender o estado interno de um sistema através de suas saídas externas.

Este artigo explora os pilares da observabilidade e como construir uma fundação sólida para trabalho de performance.

Se você não pode ver, você não pode medir. Se você não pode medir, você não pode melhorar.

Os Três Pilares

1. Métricas

Valores numéricos agregados ao longo do tempo.

cpu_usage: 75%
request_latency_p95: 120ms
error_rate: 0.5%
active_connections: 234

Características:

• Compactas e eficientes
• Ideais para dashboards e alertas
• Mostram tendências
• Perdem detalhes individuais

Quando usar:

• Monitoramento contínuo
• Alertas baseados em thresholds
• Capacity planning
• SLO tracking

2. Logs

Registros discretos de eventos.

2024-01-15 10:23:45 INFO  [req-123] User 456 logged in
2024-01-15 10:23:46 ERROR [req-124] Database timeout after 5000ms
2024-01-15 10:23:47 WARN  [req-125] Retry attempt 2 for payment service

Características:

• Ricos em contexto
• Flexíveis (texto livre ou estruturados)
• Volume pode ser muito alto
• Difíceis de agregar

Quando usar:

• Debugging de problemas específicos
• Auditoria
• Análise forense pós-incidente
• Entender sequência de eventos

3. Traces

Rastreamento de requisições através do sistema.

Request abc-123 (total: 250ms)
├── API Gateway (5ms)
├── Auth Service (20ms)
├── Product Service (180ms)
│   ├── Cache lookup (2ms)
│   ├── Database query (150ms)  ← Gargalo!
│   └── Response serialization (28ms)
└── Response sent

Características:

• Mostram fluxo end-to-end
• Identificam gargalos
• Conectam serviços distribuídos
• Overhead de instrumentação

Quando usar:

• Debugging de latência
• Entender dependências
• Identificar serviços problemáticos
• Análise de performance distribuída

Métricas de Performance Essenciais

RED Method (para serviços)

• Rate: requisições por segundo
• Errors: taxa de erros
• Duration: latência das requisições

USE Method (para recursos)

• Utilization: percentual de tempo em uso
• Saturation: trabalho enfileirado
• Errors: erros do recurso

As quatro métricas de ouro (Google SRE)

1. Latência: tempo para servir requisições
2. Tráfego: demanda no sistema
3. Erros: taxa de requisições falhando
4. Saturação: quão "cheio" está o sistema

Implementando Observabilidade

Stack comum

Aplicação
    ↓ (métricas)
Prometheus / Datadog / New Relic
    ↓
Grafana (visualização)

    ↓ (logs)
Elasticsearch / Loki / Splunk
    ↓
Kibana / Grafana

    ↓ (traces)
Jaeger / Zipkin / Datadog APM

Instrumentação

Métricas:

// Contador
requestsTotal.inc({ endpoint: '/api/users', status: 200 });

// Histograma para latência
const timer = requestDuration.startTimer();
// ... processa ...
timer({ endpoint: '/api/users' });

Logs estruturados:

logger.info({
    event: 'request_completed',
    requestId: 'abc-123',
    userId: 456,
    endpoint: '/api/users',
    duration: 120,
    status: 200
});

Traces:

const span = tracer.startSpan('database_query');
span.setTag('query', 'SELECT * FROM users');
// ... executa query ...
span.finish();

Dashboards Efetivos

Princípios

1. Hierarquia: overview → detalhe
2. Contexto: mostre o que é normal
3. Ação: cada gráfico deve informar uma decisão
4. Simplicidade: menos é mais

Dashboard de performance típico

Nível 1 - Overview:

• Taxa de requisições
• Latência p50, p95, p99
• Taxa de erros
• Throughput

Nível 2 - Por serviço:

• Métricas RED por endpoint
• Dependências e suas latências
• Recursos (CPU, memória)

Nível 3 - Detalhe:

• Queries mais lentas
• Traces de requisições específicas
• Logs filtrados

Alertas para Performance

O que alertar

Métrica	Alerta
Latência p99	> 2x do normal por 5 min
Error rate	> 1% por 2 min
Saturação CPU	> 80% por 10 min
Disponibilidade	< 99.9% em janela de 1h

Boas práticas

1. Alerte em sintomas, não causas

   • Bom: "Latência do checkout > 500ms"
   • Ruim: "CPU alta no servidor X"

2. Evite alert fatigue

   • Cada alerta deve ser acionável
   • Se você ignora regularmente, remova

3. Contexto no alerta

   ALERTA: Latência p99 em 850ms (normal: 200ms)
   Dashboard: link
   Runbook: link
   Últimos deploys: link
   

Correlação de Dados

Por que correlacionar

Deploy às 14:00
    ↓
Latência sobe às 14:05
    ↓
Logs mostram erros de conexão
    ↓
Trace revela novo código chamando DB sem índice

Sem correlação, cada ferramenta mostra parte da história.

Como correlacionar

1. Request ID em todos os logs e traces
2. Timestamps sincronizados (NTP)
3. Tags consistentes (environment, service, version)
4. Ferramentas integradas ou que exportam para mesmo destino

Custo de Observabilidade

Trade-offs

Mais dados	Custo
Mais métricas	Mais storage, mais cardinality
Mais logs	Mais storage, mais processamento
Mais traces	Overhead de instrumentação

Estratégias de otimização

1. Sampling de traces (não precisa de 100%)
2. Agregação de métricas (não precisa de 1s granularity)
3. Retenção diferenciada (dados recentes em detalhe, antigos agregados)
4. Log levels apropriados (DEBUG só quando necessário)

Observabilidade para Performance

Perguntas que você deve conseguir responder

1. Qual é a latência atual do sistema?
2. Qual era a latência há 1 semana?
3. Qual endpoint é mais lento?
4. Onde uma requisição gasta seu tempo?
5. O que mudou quando a latência aumentou?
6. Estamos próximos da saturação?

Se você não consegue responder...

...você não tem observabilidade suficiente para trabalhar performance seriamente.

Conclusão

Observabilidade não é opcional para performance — é pré-requisito.

Invista em:

1. Métricas para tendências e alertas
2. Logs para debugging
3. Traces para entender fluxos
4. Correlação para conectar os pontos
5. Dashboards que contam uma história
6. Alertas que são acionáveis

Sistemas modernos são caixas pretas sem observabilidade. Abra a caixa antes de tentar otimizá-la.