Observabilidade: métricas, logs e traces

Os três sinais

• Métricas: números ao longo do tempo (taxa de requisições, taxa de erros, latência, CPU). Baratas de armazenar e ideais para dashboards e alertas.
• Logs: registros de eventos com timestamp. Detalhe rico para depuração; use logs estruturados (JSON) com um id de requisição.
• Traces: o caminho de uma requisição entre serviços, com o tempo gasto em cada um. A ferramenta para "onde está lento?"
• Conecte-os: um trace id nos logs e um link de um pico de métrica para traces de exemplo transformam três ferramentas em uma única investigação.

O que medir

# taxa de erros em 5 minutos
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# latência no percentil 95
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

Alertas em que as pessoas confiam

• Alerte sobre sintomas que os usuários sentem (erros, latência, disponibilidade), não sobre cada causa (a CPU de um pod).
• Todo alerta precisa de um dono, uma severidade e um link para o runbook que diz o que verificar primeiro.
• Acione o plantão (page) só para o que precisa de um humano agora; mande o resto para uma fila de tickets.
• A fadiga de alertas é um problema de confiabilidade: apague ou corrija alertas ruidosos.
• Alerte pela taxa de consumo (burn rate) do SLO em vez de limites brutos (veja o tópico de SRE).

groups:
  - name: api
    rules:
      - alert: HighErrorRatio
        expr: |
          sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
            / sum(rate(http_requests_total{job="api"}[5m])) > 0.02
        for: 10m
        labels: { severity: page }
        annotations:
          summary: "Taxa de erros da API acima de 2% por 10 minutos"
          runbook: "https://wiki.example.com/runbooks/api-errors"

Hábitos

• Instrumente com um padrão (OpenTelemetry) em vez de uma biblioteca específica de fornecedor.
• Controle a cardinalidade: um label com valores ilimitados (id de usuário) pode derrubar um sistema de métricas.
• Não registre segredos nem dados pessoais nos logs.
• Revise os dashboards após cada incidente: o que teria mostrado isso antes?