Cualquier equipo que ha usado Prometheus[1] lo suficiente ha vivido el mismo ciclo. Se añaden alertas con entusiasmo y, seis meses después, el canal de on-call está inundado de ruido. Nadie las mira, y cuando pasa algo serio la señal se pierde entre falsos positivos. El problema rara vez es Prometheus: es el diseño de las reglas.

Puntos clave

  • Alerta sobre síntomas observables por el cliente (latencia, error rate, saturación), no sobre causas internas (CPU alta, memoria baja).

  • Una alerta bien escrita incluye for no trivial, etiquetas de routing, y anotaciones con summary, description, runbook y dashboard.

  • Los SLOs con burn rate multi-ventana reducen drásticamente las páginas innecesarias y alinean alertas con promesas reales al cliente.

  • El watchdog, una alerta que siempre dispara, detecta cuando el sistema de alertas está silencioso sin razón.

  • La revisión trimestral del ratio señal/ruido es tan importante como escribir las reglas iniciales.

Síntomas vs. causas: alerta sobre lo que importa al usuario

La regla más importante de diseño de alertas, defendida por el equipo SRE de Google en el libro SRE original[2], es: alerta sobre síntomas, no sobre causas.

  • Síntoma: "La tasa de errores 5xx en /api/payments supera el 1% durante 5 minutos."

  • Causa: "El pod payments-service-3 tiene CPU al 95%."

La diferencia importa porque un usuario no experimenta CPU alta: experimenta respuestas lentas o errores. Alertar sobre causas produce dos patologías simultáneas:

  • Falsos positivos: una causa puede disparar sin que el usuario note nada (el servicio escala automáticamente y absorbe el pico).

  • Falsos negativos: otra causa no prevista puede provocar un fallo sin ninguna alerta a nivel causa encendida.

Un buen conjunto de reglas parte de síntomas observables para el cliente (latencia, error rate, saturación) y mantiene las causas como dashboards de diagnóstico, no como alertas que paginan.

Anatomía de una alerta bien escrita

Una regla de Prometheus con múltiples ventanas, anotaciones completas y etiquetas de routing:

- alert: ApiHighErrorRate
  expr: |
    sum by (service) (
      rate(http_requests_total{status=~"5.."}[5m])
    )
    /
    sum by (service) (
      rate(http_requests_total[5m])
    )
    > 0.01
  for: 10m
  labels:
    severity: page
    team: platform
  annotations:
    summary: "API {{ $labels.service }} error rate above 1%"
    description: |
      Service {{ $labels.service }} has had >1% 5xx error rate for the
      last 10 minutes (current: {{ $value | humanizePercentage }}).
    runbook_url: "https://runbooks.example.com/api-error-rate"
    dashboard_url: "https://grafana.example.com/d/abc/api-overview"

Cuatro elementos que no pueden faltar:

  • for no trivial. Entre 5 y 15 minutos absorbe transitorios sin retrasar excesivamente la respuesta a incidentes reales.

  • Etiquetas de routing claras. severity (page / ticket / info) + team permiten a Alertmanager enrutar a canales distintos y cada equipo recibe solo lo suyo.

  • Anotaciones completas. summary (una línea), description (contexto con valores interpolados), runbook_url (qué hacer) y dashboard_url (dónde mirar). Una alerta sin runbook es una invitación al pánico.

  • PromQL correcto. Usar rate() sobre contadores, no increase() directamente. Agrupar por las dimensiones que importan para el routing.

Logotipo de Prometheus: el sistema de monitorización y alertas que complementa el artículoLogotipo de Prometheus: el sistema de monitorización y alertas que complementa el artículo (Imagen: Alexander Schwartz (ahus1), Apache License 2.0, vía Wikimedia Commons)

SLOs y burn rate multi-ventana

El patrón que ha ganado adopción más rápida es el de alertas basadas en SLO con burn rate multi-ventana y multi-umbral. Google SRE lo popularizó y el capítulo 5 del SRE Workbook[3] lo detalla.

La idea: define un SLO (por ejemplo, 99.9% de éxito en 30 días, permitiendo un error budget de 0.1%). En lugar de alertar sobre tasa de error absoluta, alerta cuando estás quemando el error budget más rápido de lo sostenible:

  • Burn rate > 14.4x durante 1h → alarma crítica (consumirías el budget del mes en 2 días).

  • Burn rate > 6x durante 6h → alarma seria (consumirías el budget en 5 días).

  • Burn rate > 1x durante 24h → alarma de tendencia (vas camino de gastar el budget).

Esto alinea las alertas con promesas reales al cliente (el SLO) y reduce drásticamente las páginas innecesarias. Sloth[4] y Pyrra[5] generan estas reglas automáticamente desde una definición declarativa de SLO.

Esta infraestructura de monitorización gana valor combinada con la observabilidad del kernel que ofrece eBPF. Las métricas de alto nivel en Prometheus y la granularidad del kernel en eBPF se complementan, no compiten.

El watchdog: alerta que siempre está encendida

Un error común: alertas silenciosas. Prometheus deja de scrapear, Alertmanager cae, o un error de configuración hace que las reglas no se evalúen. No llega ninguna alerta, pero tampoco llega ningún ping. Dos semanas después descubres que tu observabilidad ha estado muerta.

La solución canónica: una alerta watchdog que siempre dispara por diseño:

- alert: Watchdog
  expr: vector(1)
  labels:
    severity: none
  annotations:
    summary: "Prometheus is alive"

Se envía a un receptor que espera recibirla cada X minutos. Si no llega durante un umbral, el receptor (Dead Man’s Snitch[6] o Healthchecks.io[7], por ejemplo) dispara su propia alerta. Esto convierte el silencio en señal, en vez de ambigüedad.

Qué pulir cada trimestre

Las alertas no son "configure and forget". Un ritual útil para equipos on-call:

  • Revisión trimestral de top-N páginas. ¿Qué alertas dispararon más? ¿Cuántas resultaron en acción real? Las que siempre se acknowledgean sin acción se deben eliminar o ajustar.

  • Post-mortems con ítem "alertas". Cada incidente enseña: ¿la alerta adecuada llegó a tiempo? ¿Alguna alerta irrelevante se disparó en paralelo?

  • Pruebas de alertas nuevas en staging. Simula el síntoma antes de subir la regla a producción.

Esta disciplina de mejora continua conecta con los principios del pensamiento de diseño aplicados a operaciones. Los mejores runbooks y alertas se diseñan desde la perspectiva del operador bajo presión, no del autor con todo el contexto. Y como indica nuestra guía de instalación de Traefik con Docker Compose, la observabilidad empieza en la capa de infraestructura antes de llegar a las métricas de negocio.

Conclusión

Cuatro principios reducen la fatiga de guardia y mejoran la respuesta a incidentes reales. Alerta sobre síntomas, basa la gravedad en SLOs con burn rate, monitoriza el propio sistema de alertas con un watchdog y revisa trimestralmente el ratio señal/ruido. La diferencia entre un canal on-call útil y uno ignorado está en el diseño de las reglas, no en la cantidad de métricas que se recogen.

Preguntas frecuentes

¿Cuánto tiempo debería poner en el `for` de una alerta de Prometheus?

Entre 5 y 15 minutos: un for de ese rango absorbe los transitorios sin retrasar excesivamente la respuesta a incidentes reales. Un for trivial dispara con cada pico momentáneo y alimenta el ruido que acaba haciendo que el canal de on-call se ignore. Junto al for, la regla necesita etiquetas de routing (severity con valores page, ticket o info, y team) y anotaciones con summary, description, runbook_url y dashboard_url; una alerta sin runbook es una invitación al pánico.

¿Cómo me entero de que Prometheus o Alertmanager han dejado de funcionar si no llega ninguna alerta?

Con una alerta watchdog que dispara siempre por diseño: expr: vector(1) con severity: none. Se envía a un receptor externo que espera recibirla cada X minutos, por ejemplo Dead Man's Snitch o Healthchecks.io. Si no llega dentro del umbral, es el receptor quien dispara su propia alerta. Así el silencio se convierte en señal en vez de ambigüedad, y evitas descubrir dos semanas tarde que Prometheus dejó de scrapear, Alertmanager cayó o un error de configuración impedía evaluar las reglas.

¿Qué umbrales de burn rate uso para alertar sobre un SLO?

Para un SLO como 99.9% de éxito en 30 días (error budget del 0.1%), el patrón multi-ventana de Google SRE alerta cuando quemas el budget más rápido de lo sostenible. Un burn rate superior a 14.4x durante 1 hora es alarma crítica: consumirías el budget del mes en 2 días. Superior a 6x durante 6 horas es alarma seria (5 días), y superior a 1x durante 24 horas es alarma de tendencia. Sloth y Pyrra generan estas reglas automáticamente desde una definición declarativa del SLO.

Fuentes:

  1. Google SRE Book: Monitoring Distributed Systems[2]
  2. Google SRE Workbook: Alerting on SLOs[3]
  3. Sloth: generador de reglas SLO para Prometheus[4]
  4. Pyrra: herramienta de SLOs declarativos para Kubernetes[5]
  5. Dead Man’s Snitch: monitorización por ausencia de señal[6]
  6. Healthchecks.io: monitorización de cron jobs y heartbeats[7]

Este artículo también está disponible en inglés: Prometheus: Writing Alerts That Won’t Get Ignored.

Fuentes

  1. Prometheus
  2. libro SRE original
  3. SRE Workbook
  4. Sloth
  5. Pyrra
  6. Dead Man’s Snitch
  7. Healthchecks.io