Observabilidad: métricas, logs y traces

Las tres señales

• Métricas: números a lo largo del tiempo (tasa de solicitudes, tasa de errores, latencia, CPU). Baratas de almacenar e ideales para dashboards y alertas.
• Logs: registros de eventos con timestamp. Detalle rico para depurar; usa logs estructurados (JSON) con un id de solicitud.
• Traces: el camino de una solicitud a través de los servicios, con el tiempo gastado en cada uno. La herramienta para "¿dónde está lento?"
• Conéctalos: un trace id en los logs y un enlace desde un pico de métrica a traces de ejemplo convierten tres herramientas en una sola investigación.

Qué medir

# tasa de errores en 5 minutos
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# latencia en el percentil 95
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

Alertas en las que la gente confía

• Alerta sobre síntomas que sienten los usuarios (errores, latencia, disponibilidad), no sobre cada causa (la CPU de un pod).
• Toda alerta necesita un dueño, una severidad y un enlace al runbook que diga qué revisar primero.
• Haz page solo por lo que necesita a una persona ahora; manda el resto a una cola de tickets.
• La fatiga de alertas es un problema de confiabilidad: borra o corrige las alertas ruidosas.
• Alerta por la tasa de consumo (burn rate) del SLO en lugar de umbrales crudos (ver el tema 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: "Tasa de errores de la API por encima de 2% durante 10 minutos"
          runbook: "https://wiki.example.com/runbooks/api-errors"

Hábitos

• Instrumenta con un estándar (OpenTelemetry) en lugar de una biblioteca específica de un proveedor.
• Controla la cardinalidad: un label con valores ilimitados (id de usuario) puede tumbar un sistema de métricas.
• No registres secretos ni datos personales en los logs.
• Revisa los dashboards después de cada incidente: ¿qué lo habría mostrado antes?