Prometheus: cómo escribir alertas que no se ignoren

Actualizado: 2026-05-03

Cualquier equipo que ha usado Prometheus^[1] lo suficiente ha vivido el mismo ciclo: se añaden alertas con entusiasmo, 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:

1. Falsos positivos: una causa puede disparar sin que el usuario note nada (el servicio escala automáticamente y absorbe el pico).
2. 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 desde el punto de vista del 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.

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, popularizado por Google SRE y detallado en el capítulo 5 del SRE Workbook^[3].

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 es especialmente valiosa cuando se combina con la observabilidad a nivel de 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 — típicamente Dead Man’s Snitch^[6] o Healthchecks.io^[7] — 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

Alertar sobre síntomas, basar la gravedad en SLOs con burn rate, monitorizar el propio sistema de alertas con un watchdog y revisar trimestralmente el ratio señal/ruido: estos cuatro principios reducen la fatiga de guardia y mejoran la respuesta a incidentes reales. 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.

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