Como usar observabilidade para identificar gargalos

1. Fundamentos da observabilidade aplicada a gargalos

Em sistemas distribuídos modernos, um gargalo representa qualquer componente que limita a capacidade total do sistema, criando um efeito de "funil" onde requisições se acumulam e a performance degrada. Diferente do monitoramento tradicional, que apenas alerta quando algo quebra, a observabilidade permite investigar por que algo está lento ou falhando.

Os três pilares da observabilidade atuam em conjunto na detecção de gargalos:

  • Métricas: indicam o que está acontecendo (latência, throughput, utilização)
  • Logs: fornecem detalhes contextuais sobre eventos específicos
  • Traces: revelam o caminho completo de uma requisição entre serviços

A diferença crucial está na abordagem: monitoramento reativo espera o incidente ocorrer, enquanto observabilidade proativa permite detectar degradações graduais antes que se tornem críticas.

2. Mapeamento de métricas-chave para identificar lentidão

Para identificar gargalos, métricas de latência são as mais reveladoras. Os percentis p50, p95 e p99 contam histórias diferentes:

# Exemplo de métricas coletadas pelo Prometheus
http_request_duration_seconds{quantile="0.5"} 0.045
http_request_duration_seconds{quantile="0.95"} 0.320
http_request_duration_seconds{quantile="0.99"} 2.150

Quando p99 dispara enquanto p50 permanece baixo, há um gargalo intermitente afetando uma minoria de requisições. Se p50 também sobe, o gargalo é sistêmico.

O throughput (requisições por segundo) e a taxa de erros complementam a análise:

# Métricas de throughput e erros
http_requests_total{status="200"} 14500
http_requests_total{status="500"} 230
http_requests_total{status="429"} 890

Um aumento em erros 429 (Too Many Requests) sugere gargalo em filas ou rate limiting. Erros 500 indicam falhas internas do serviço.

Utilização de recursos como CPU e memória ajudam a localizar a causa raiz:

# Métricas de infraestrutura
node_cpu_seconds_total{mode="user"} 0.87
node_memory_MemAvailable_bytes 2.4e9

3. Rastreamento distribuído para localizar o ponto exato do gargalo

Com traces distribuídos, cada requisição é decomposta em spans que representam operações individuais. Ao configurar o OpenTelemetry:

# Configuração de span para um serviço de pagamento
span_name: "processar_pagamento"
span_kind: SERVER
start_time: 1712345678.123
end_time: 1712345679.456
attributes:
  servico: "payment-service"
  metodo: "POST /api/payments"
  status: "error"

Ao analisar o waterfall chart no Jaeger, identificamos qual serviço consome mais tempo:

# Análise visual de traces
Serviço A: 10ms (gateway)
Serviço B: 45ms (autenticação)
Serviço C: 1200ms (banco de dados)  # <-- GARGALO
Serviço D: 5ms (notificação)

Flame graphs mostram onde o tempo está sendo gasto dentro de cada serviço, revelando funções específicas que causam lentidão.

4. Análise de logs estruturados para contexto adicional

Logs estruturados permitem correlação direta com traces através de IDs únicos:

# Log com correlation_id para rastreamento
{
  "timestamp": "2024-03-15T10:30:00Z",
  "level": "WARN",
  "message": "Timeout ao conectar no banco de dados",
  "service": "order-service",
  "trace_id": "abc123def456",
  "duration_ms": 5000,
  "retry_count": 3
}

Padrões de log que indicam contenção incluem:

# Logs que sugerem gargalo
[WARN] Connection pool exhausted - waiting for available connection
[ERROR] Circuit breaker opened - too many failures
[INFO] Queue depth: 1500 messages - processing rate: 100 msg/s

Filtrar logs por trace_id permite reconstruir a jornada completa de uma requisição lenta.

5. Dashboards operacionais para visualização de gargalos

No Grafana, dashboards focados em gargalos devem combinar múltiplas fontes:

# Query PromQL para painel de latência
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# Query para taxa de erros por serviço
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)

Alertas baseados em percentis são mais eficazes que médias:

# Alerta no Alertmanager
- alert: HighLatencyP99
  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 1
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Latência P99 acima de 1 segundo"

Com Loki, consultas históricas permitem comparar padrões atuais com baseline:

# Query Loki para logs de timeout
{app="order-service"} |= "timeout" | json | duration_ms > 3000

6. Estratégias práticas de debugging com observabilidade

O pipeline de investigação segue três passos:

  1. Métrica: Identificar degradação no painel (p95 subiu de 200ms para 800ms)
  2. Trace: Abrir trace da requisição lenta e localizar span culpado
  3. Log: Filtrar logs daquele trace para entender contexto

Exemplo real — gargalo em banco de dados vs. rede:

# Caso 1: Gargalo em banco de dados
Spans mostram: 950ms em "query_mysql", 20ms no restante
Logs: "slow query: SELECT * FROM orders WHERE ..."

# Caso 2: Gargalo de rede
Spans mostram: 500ms em "http_call_external", 200ms distribuídos
Métricas: network_latency_seconds subiu 300%
Logs: "connection reset by peer" em serviço externo

Ferramentas complementares como Sentry capturam exceções com stack trace, enquanto Prometheus fornece métricas históricas para validação cruzada.

7. Automação e ações corretivas baseadas em observabilidade

Com métricas em tempo real, podemos automatizar respostas a gargalos:

# Configuração HPA no Kubernetes baseada em métricas personalizadas
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 500

Runbooks para gargalos recorrentes devem incluir:

# Runbook: Gargalo em pool de conexões de banco
1. Verificar métricas de conexões ativas no Grafana
2. Identificar queries mais lentas via pg_stat_activity
3. Verificar traces de serviços com maior tempo de DB
4. Aumentar pool de conexões ou adicionar réplicas de leitura
5. Criar índice para queries lentas identificadas
6. Monitorar impacto após alteração

O feedback loop entre desenvolvimento e operações garante que gargalos identificados gerem melhorias no código, não apenas escalonamento.

Referências