Alertmanager: el árbol de routing que no despierta al equipo a las 3 de la mañana
Índice de contenidos
Actualizado: 2026-05-03
Alertmanager, la pieza de notificación del ecosistema Prometheus, es donde una alerta mal definida se convierte en una cascada de avisos a PagerDuty a las tres de la madrugada — o donde, bien gestionada, mantiene la salud del equipo. La diferencia no está en el motor de alertas, sino en la configuración que lo rodea. Tras años viendo configuraciones reales, la conclusión es incómoda: casi nadie tiene un Alertmanager bien afinado. Este artículo cubre los patrones que sí funcionan con la versión 0.27 y Prometheus 2.54.
Puntos clave
- Un único receptor de Slack sin agrupación ni inhibiciones es la configuración ingenua que lleva al canal ignorado en una semana.
- El árbol de routing debe diseñarse de lo más específico a lo más general — cada rama añadida sin criterio es deuda técnica de observabilidad.
- Las reglas de inhibición son la herramienta más infrautilizada y la de mayor impacto durante incidentes regionales.
- Una alerta crítica es aquella que justifica despertar a alguien: forzar esa definición explícita cambia el comportamiento del equipo.
- La revisión trimestral de señal contra ruido vale más que cualquier nueva regla de alerting.
El problema de partida
El despliegue ingenuo consiste en un único receptor de Slack al que van todas las alertas, sin agrupar, sin clasificar por severidad y sin inhibiciones. El resultado aparece a la semana: el canal se ignora por inercia, las alertas reales se pierden en el ruido y, cuando llega un incidente de verdad, nadie se entera hasta que un cliente llama. La fatiga de alertas no es un concepto académico; es un fallo operativo medible en tiempo medio de detección.
El error conceptual suele ser tratar las alertas como eventos independientes. En realidad, una caída de un nodo genera docenas de alertas correlacionadas, y un incidente regional puede disparar cientos en segundos. Sin una estructura que las clasifique, agrupe y priorice, la consola se vuelve un flujo ilegible.
La anatomía correcta
Una configuración sana se apoya en seis elementos que trabajan juntos:
- Árbol de routing: decide qué receptor atiende cada alerta según sus etiquetas.
- Agrupación: combina alertas relacionadas en una única notificación.
- Reglas de inhibición: silencian los efectos cuando se conoce la causa.
- Silencios: cortan ruido durante mantenimientos puntuales.
- Canales por severidad: separan lo que interrumpe el sueño de lo que espera a horario de oficina.
- Rotación de guardia: garantiza que la notificación llega a la persona adecuada.
Ninguno resuelve el problema por sí solo. Lo interesante es cómo interactúan: la agrupación reduce volumen, la inhibición elimina redundancia, el routing dirige el flujo filtrado y los silencios son la válvula de escape para lo planificado.
El árbol de routing como mapa mental
El árbol de routing es el corazón de Alertmanager. Conceptualmente es un árbol de decisión recursivo donde cada alerta desciende desde la raíz probando coincidencias de etiquetas, y el primer nodo que coincide gana — salvo que se marque explícitamente que continúe. La regla de oro: diseñar de lo más específico a lo más general, dejando la ruta por defecto para lo que no encaja en ningún patrón.
route:
group_by: [alertname, cluster, service]
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: default-slack
routes:
- match: { severity: critical }
receiver: pagerduty-oncall
group_wait: 10s
continue: true
- match_re: { service: ^(postgres|mysql|redis)$ }
receiver: dba-slack
- match: { severity: warning }
receiver: jira-tickets
group_interval: 30mLa rama crítica dispara hacia PagerDuty con un group_wait corto y continúa hacia Slack para dejar rastro. Las alertas de bases de datos se desvían a un receptor dedicado del equipo DBA. Los avisos de severidad intermedia generan tickets en Jira con un intervalo mayor — nadie necesita un ticket nuevo cada cinco minutos. La telemetría informativa solo se emite en horario laboral.
La tentación de añadir rutas sin fin es real. Un árbol con treinta ramas se vuelve imposible de razonar. Revisarlo trimestralmente y podar lo que ya no aporta es más valioso que cualquier nueva regla. Este árbol se complementa con las reglas de Prometheus descritas en SLOs y error budgets con Prometheus: el routing de Alertmanager solo es tan bueno como las alertas que recibe.
Agrupación: el compromiso fundamental
La agrupación se controla con tres parámetros en tensión deliberada:
group_wait: tiempo que espera antes de enviar la primera notificación de un grupo nuevo. Valores bajos aceleran la detección pero fragmentan el mensaje.group_interval: cada cuánto se añaden alertas al grupo existente.repeat_interval: cada cuánto se reenvía un grupo ya notificado mientras siga activo.
El compromiso central es claro: agrupar agresivamente reduce volumen y fatiga, pero puede retrasar la detección de síntomas que merecerían atención inmediata. Agrupar finamente acerca cada alerta a su origen, pero convierte un incidente grande en un torrente inmanejable. En la práctica, agrupar por alertname, cluster y service funciona bien para la mayoría de flotas: suficiente contexto para ser legible y suficiente granularidad para no ocultar problemas distintos.
Inhibición: decir lo obvio una sola vez
Cuando un nodo cae, las alertas de los pods que viven en él no aportan información nueva — son consecuencia directa de la causa conocida. Las reglas de inhibición expresan eso: si la alerta A está activa, silenciar las alertas B que cumplan una condición de igualdad de etiquetas.
El patrón mental útil es distinguir entre alertas de causa y alertas de efecto:
- Causa: el nodo se ha caído, la red se ha perdido, la base de datos no acepta conexiones.
- Efecto: los pods no arrancan, las peticiones fallan, los jobs no pueden conectar.
Quien está de guardia necesita ver las causas, no un listado de cincuenta efectos. Regla práctica: si una alerta se puede deducir de otra activa, probablemente debería estar inhibida.
Silencios, intervalos de tiempo y el ritmo humano
Los silencios temporales (gestionados desde la interfaz o con amtool) son el mecanismo para ventanas de mantenimiento puntuales. Los intervalos de tiempo, introducidos de forma madura en las últimas versiones, permiten expresar en la propia configuración que ciertas alertas solo se envíen en horario laboral o que las informativas se silencien los fines de semana.
Distinguir entre ambos es útil: los silencios documentan excepciones, los intervalos codifican políticas estables.
Una política que funciona en equipos pequeños:
- Crítico: siempre página.
- Aviso: solo genera ticket en horario laboral.
- Informativo: nunca interrumpe.
Esto no es rigidez — es respeto por el sueño ajeno. Y, sobre todo, obliga a que el criterio para marcar algo como crítico sea explícito: una alerta crítica es aquella que justifica despertar a alguien. Si no lo justifica, no es crítica.
Rotaciones, escalado y el antídoto contra la fatiga
Alertmanager no gestiona rotaciones; esa responsabilidad recae en PagerDuty u OpsGenie, que saben quién está de guardia, aplican escalado cuando el primario no reconoce en X minutos y mantienen el calendario. Alertmanager entrega al equipo; la herramienta externa entrega a la persona. Esta separación evita reinventar la rueda.
El verdadero antídoto contra la fatiga no está en más herramientas sino en revisión periódica. Mensualmente conviene revisar:
- Cuántas alertas han saltado.
- Cuántas se han reconocido sin acción.
- Cuántas se han silenciado manualmente.
Una tasa alta de silencios manuales indica alertas mal calibradas. Una tasa baja de reconocimiento indica un canal ya ignorado. Ambas señales son tratables si se miden. Para el contexto más amplio de respuesta a incidentes, ver incident response blameless.
Conclusión
Un Alertmanager bien configurado es la diferencia entre un equipo de guardia que duerme y uno que renuncia. Ninguno de los patrones descritos resuelve el problema por sí solo — agrupación, inhibición, routing por severidad, intervalos horarios — pero combinados construyen una experiencia sostenible. La inversión merece la pena: cada hora ahorrada en fatiga de alertas se convierte en productividad y, sobre todo, en personas que siguen queriendo estar de guardia al año siguiente. Para empezar desde cero, kube-prometheus-stack aporta una base razonable. Para equipos ya establecidos, la revisión trimestral de señal contra ruido es probablemente la mejor hora que van a invertir este mes.
