Observability: os 3 pilares (logs, métricas, traces) e por que não basta

Monitoring é velho — vem dos anos 90, de sistemas monolíticos onde o operador sabia exatamente o que podia dar errado (disk cheio, CPU em 100%, serviço caiu). Você configurava alertas pra esses N cenários e pronto.

Observability (conceito da teoria de controle, Kalman 1960) começou a ser importada pra software em ~2017 (Honeycomb, Charity Majors). A tese: sistemas distribuídos modernos têm muito mais estados possíveis do que qualquer engenheiro consegue antecipar. Em vez de alertar sobre N coisas conhecidas, você instrumenta tudo o suficiente pra descobrir o que deu errado.

OBSERVABILITY
   ├─ LOGS     ──── "o que aconteceu" (evento textual/JSON por linha)
   ├─ METRICS  ──── "quanto" (números agregados no tempo: rate, latência, count)
   └─ TRACES   ──── "como" (path de uma request atravessando N serviços)

Exemplo: mesmo incidente visto pelos 3 pilares.

Problema: usuário reporta que checkout tá lento

MÉTRICAS (Prometheus):
  http_request_duration_seconds{path="/checkout"} p99 = 4.2s
  (era 200ms ontem — anomalia clara)
  → mas por quê? métricas não sabem.

LOGS (JSON):
  {"level":"warn","msg":"slow query","query":"SELECT * FROM carts...","dur_ms":3800}
  {"level":"info","msg":"checkout completed","user":"u42","dur_ms":4100}
  → hipótese: query lenta. Mas qual cart? Quantos usuários afetados?

TRACES (Jaeger):
  span: POST /checkout (4.1s)
   ├─ span: CartService.getCart (3.8s)  ← gargalo!
   │   └─ span: db.query (3.7s, query_type="cart_items_join")
   ├─ span: PaymentService.charge (150ms)
   └─ span: ShippingService.schedule (40ms)
  → conclusão: join no cart_items explodiu. Correlacionar com deploy de hoje.

Os 3 pilares são complementares. Sozinhos, cada um é limitado. Juntos, permitem ir do "algo está lento" pro "essa query específica, nesse código, nesse deploy" em minutos.

Cardinalidade de uma métrica = número de combinações únicas de labels. Em Prometheus e similares, cada combinação é uma série temporal separada — com seu próprio buffer, índice e retenção.

# baixa cardinalidade — ok
http_requests_total{method="GET", status="200"} 12345
http_requests_total{method="POST", status="500"} 42
# ~ 6 métodos × 10 status = 60 séries, ok

# alta cardinalidade — PERIGO
http_requests_total{method, status, path, user_id} 1
# 5 métodos × 10 status × 500 paths × 1_000_000 user_ids = 25 bilhões de séries
# Prometheus capota. Latência de query em minutos.

Regras práticas pra labels de métricas:

• Nunca use: user_id, email, session_id, trace_id, uuid, timestamp, URL completa com query params
• OK: enum-like (method, status, region), low-cardinality features (tier: free/pro/ent, os: ios/android)
• Máximo: 10-50k séries únicas por métrica em Prometheus
• Se precisa alta cardinalidade: use events/traces (não métricas) ou TSDB moderno (VictoriaMetrics, Mimir, Cortex)

Metrics são lossy (agregadas). Logs são textuais (difíceis de consultar estruturado). Traces são hierárquicos (bom pra latência). Wide events ficam no meio: cada request gera um evento JSON com 30-100 fields — user, tenant, version, region, cache hit, status, latency, feature flags, db stats, etc.

// um wide event por request (exemplo Honeycomb-style)
{
  "timestamp": "2026-04-16T14:23:45.123Z",
  "service": "checkout-api",
  "version": "v2.3.1-a4f8",
  "env": "production",
  "region": "us-east-1",
  "endpoint": "POST /checkout",
  "status": 200,
  "duration_ms": 423,
  "user_id": "u_42",
  "user_tier": "pro",
  "tenant_id": "acme-corp",
  "feature_flag.new_payment_flow": true,
  "feature_flag.cdn_enabled": false,
  "cart_items_count": 12,
  "cart_total_cents": 15000,
  "db.query_count": 5,
  "db.cache_hit_ratio": 0.8,
  "trace_id": "abc123...",
  "request_id": "req_xyz"
}

Com wide events, em 1 minuto no dashboard você pode: "mostre latência p99 por region E feature_flag.new_payment_flow E user_tier". Sem pré-agregação, sem dashboards pré-configurados. Honeycomb e Datadog (Continuous Profiler + RUM) são lideres; ferramentas open-source crescendo (Grafana Tempo aceita span events, ClickHouse + Vector é stack DIY popular).

Profiling tradicional: você liga em ambiente de staging, roda carga, analisa offline. Problema: bugs de performance em produção raramente reproduzem fora dela. Continuous profiling roda em produçãocom overhead <3% (via eBPF, instrumentação em runtime), gerando flamegraphs sempre disponíveis.

CPU flamegraph do momento do incidente:

|████████████████████████████████| 100% CPU  (root)
|████████████████████████| 65% checkout_handler
|████████████| 42% getCartItems
|█████| 28% db.query (N+1 detectado!)
|██| 8% json.serialize
|███| 13% paymentClient.charge
|██████| 25% rateLimiter.check

O maior trauma operacional pós-K8s é a fatura do Datadog. Alguns padrões pra não quebrar:

• Sampling em traces: 1-10% em produção, 100% em staging. Rejeite spans de health checks.
• Log levels apropriados: DEBUG nunca em prod. INFO moderado. Truncar fields gigantes.
• Retention tiered: hot 7d, warm 30d, cold S3 90d+. Datadog permite; self-host precisa configurar.
• Cardinalidade cap: Prometheus label_limit, Grafana Mimir limits per tenant.
• Drop filtering: OTel Collector processor pra dropar spans/logs irrelevantes antes do backend.
• Derived metrics: extrair métricas de logs (se é a mesma info, não duplique).