Monitoreo y Alertas — Métricas, Logs y Dashboards

Introducción

No puedes mejorar lo que no puedes medir. El monitoreo te dice cuándo los sistemas están enfermos; las alertas te despiertan cuando la acción es necesaria. Pero alertas mal diseñadas crean fatiga, burnout y páginas ignoradas. A continuación: los tres pilares de observabilidad, cómo diseñar alertas útiles y cómo construir dashboards que ayudan durante incidentes.

Los Tres Pilares de la Observabilidad

Pilar	Qué Responde	Herramientas Ejemplo
Métricas	¿Qué está haciendo el sistema en el tiempo?	Prometheus, Datadog, CloudWatch
Logs	¿Qué pasó en detalle?	ELK, Loki, Splunk
Traces	¿A dónde fue la solicitud y cuánto duró cada paso?	Jaeger, Zipkin, OpenTelemetry

Métricas

Datos de series de tiempo sobre salud del sistema. Baratos de almacenar, rápidos de consultar.

from prometheus_client import Counter, Histogram

request_count = Counter('http_requests_total', 'Total requests', ['method', 'endpoint'])
request_latency = Histogram('http_request_duration_seconds', 'Request latency', ['endpoint'])

Logs

Registros de eventos discretos.

{
  "timestamp": "2024-06-12T10:23:45Z",
  "level": "error",
  "service": "payment-api",
  "trace_id": "abc-123",
  "message": "Payment processor returned 503"
}

Regla: Usa logs estructurados (JSON) en producción. Son parseables, buscables y se correlacionan con traces.

Traces

Sigue una solicitud individual a través de servicios. Consulta Distributed Tracing para implementación.

[Gateway] 2ms → [Auth] 15ms → [Orders] 45ms → [DB] 30ms → [Payment] 120ms

Método RED (para Servicios)

Métrica	Pregunta	Umbral Ejemplo
Rate	¿Cuántos requests por segundo?	Línea base: 1000 req/s
Errors	¿Qué porcentaje de requests falla?	Alertar si > 0.1% por 2 minutos
Duration	¿Cuánto tardan los requests?	Alertar si p99 > 500ms por 5 minutos

Método USE (para Recursos)

Métrica	Pregunta	Umbral Ejemplo
Utilization	¿Qué tan ocupado está el recurso?	CPU > 80%
Saturation	¿Cuánto trabajo está encolado?	Profundidad de cola de disco > 10
Errors	¿Cuántos errores ocurrieron?	Drops de paquetes de red > 0.1%

Diseño de Alertas

Buenas Alertas Son Útiles

Responden tres preguntas:

1. ¿Qué está mal? — nombre claro de métrica y umbral violado
2. ¿Dónde está mal? — nombre de servicio, región, ambiente
3. ¿Qué debería hacer? — link a runbook o acción sugerida

Severidad de Alertas

Severidad	Tiempo de Respuesta	Acción
Page (Crítica)	5 minutos	Despertar a alguien
Ticket (Advertencia)	4 horas	Crear ticket para horario laboral
Log (Info)	Ninguno	Registrar para dashboards y análisis

Regla: Si una alerta suena y nadie toma acción, degrádala a ticket o log.

Diseño de Dashboards

La Regla de 5 Segundos

Un dashboard debería decirte si el sistema está saludable en 5 segundos.

Fila	Propósito	Paneles Ejemplo
Fila 1: Salud	¿El sistema está arriba?	Tasa de error, SLA de disponibilidad, throughput
Fila 2: Latencia	¿Somos suficientemente rápidos?	p50, p95, p99 latencia por endpoint
Fila 3: Recursos	¿Nos estamos quedando sin capacidad?	CPU, memoria, disco, red
Fila 4: Negocio	¿Los usuarios están felices?	Registros, checkouts, sesiones activas

Lo que funciona

• Instrumenta antes de necesitarlo — agregar métricas durante un incidente es demasiado tarde
• Usa percentiles, no promedios — los promedios ocultan outliers; p95 y p99 cuentan la historia real
• IDs de correlación en todas partes — vincula logs, métricas y traces a un request ID único
• Alerta sobre síntomas, no causas — “usuarios no pueden hacer checkout” es mejor que “CPU está alta”
• Revisa alertas trimestralmente — elimina ruido, ajusta umbrales, consolida duplicados

Errores Comunes

• Alertar sobre cada posible modo de fallo — la fatiga de alertas mata la calidad de respuesta
• No tener una métrica “canary” — despliega un cambio y observa una sola métrica dorada
• Ignorar cambios de línea base — si p99 se desplaza de 100ms a 300ms en un mes, investiga
• Dashboards sin dueños — alguien debe poseer y mantener cada dashboard

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de alerting y alerts para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica monitoreo y alertas — métricas, logs y dashboards cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Temas Avanzados

Escenario: Sistema de Alertas para E-commerce

# Prometheus alerting rules
groups:
  - name: payment-service
    rules:
      # SLO: tasa de error > 1% durante 5 min
      - alert: PaymentErrorRateHigh
        expr: |
          sum(rate(http_requests_total{job="payment",status=~"5.."}[5m]))
          / sum(rate(http_requests_total{job="payment"}[5m]))
          > 0.01
        for: 5m
        labels:
          severity: page
          team: payments
        annotations:
          summary: "Payment error rate > 1%"
          description: "Error rate is {{ $value | humanizePercentage }}"
          runbook: "https://wiki/runbooks/payment-errors"

      # SLO: latencia p99 > 500ms durante 10 min
      - alert: PaymentLatencyHigh
        expr: |
          histogram_quantile(0.99,
            rate(http_duration_bucket{job="payment"}[10m]))
          > 0.5
        for: 10m
        labels:
          severity: page
          team: payments
        annotations:
          summary: "Payment p99 latency > 500ms"
          runbook: "https://wiki/runbooks/payment-latency"

      # SLO burn rate: 14x en 1h
      - alert: PaymentSLOBurnRate
        expr: |
          (
            sum(rate(http_requests_total{job="payment",status=~"5.."}[1h]))
            / sum(rate(http_requests_total{job="payment"}[1h]))
          ) > 14 * 0.001
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Payment SLO burn rate > 14x"

      # Warning: throughput anormal
      - alert: PaymentThroughputAnomaly
        expr: |
          rate(http_requests_total{job="payment"}[5m])
          < 100
        for: 10m
        labels:
          severity: ticket
        annotations:
          summary: "Payment throughput < 100 req/s"

  - name: infrastructure
    rules:
      # Disco: > 85% en 30 min
      - alert: DiskSpaceLow
        expr: |
          (1 - node_filesystem_avail_bytes
           / node_filesystem_size_bytes) > 0.85
        for: 30m
        labels:
          severity: ticket
        annotations:
          summary: "Disk > 85% on {{ $labels.instance }}"

      # Memoria: OOM inminente
      - alert: MemoryExhausted
        expr: |
          (1 - node_memory_MemAvailable_bytes
           / node_memory_MemTotal_bytes) > 0.95
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Memory > 95% on {{ $labels.instance }}"

# Alertmanager routing
route:
  receiver: default
  group_by: [alertname, team]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: [severity="page"]
      receiver: pagerduty
      group_wait: 0s
    - matchers: [severity="ticket"]
      receiver: jira
      group_wait: 10m

receivers:
  - name: pagerduty
    pagerduty_configs:
      - service_key: $PAGERDUTY_KEY
  - name: jira
    webhook_configs:
      - url: "https://jira.example.com/alerts"
  - name: default
    slack_configs:
      - channel: "#alerts"

Como elimino alert fatigue?

1. Audita alertas cada trimestre: elimina las que nunca disparan o siempre disparan. 2. Usa severity levels: page solo para impacto en usuarios. 3. Agrupa alertas relacionadas (Alertmanager group_by). 4. Configura repeat_interval para no re-notificar. 5. Cada alerta debe tener un runbook. 6. Mide el numero de alertas por on-call shift: > 5/noche es excesivo.

End of document. Review and update quarterly.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.