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.
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 por teléfono. 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. El árbol de routing decide qué receptor atiende cada alerta según sus etiquetas. La agrupación combina alertas relacionadas en una única notificación. Las reglas de inhibición silencian los efectos cuando se conoce la causa. Los silencios cortan ruido durante mantenimientos. Los canales por severidad separan lo que interrumpe el sueño de lo que espera a horario de oficina. Y una rotación de guardia bien definida garantiza que la notificación llega a la persona adecuada.
Ninguno de estos elementos 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 es diseñar el árbol 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.
En una configuración típica la rama crítica dispara hacia PagerDuty con un group_wait corto, de diez segundos, y además continúa hacia Slack para dejar rastro. Las alertas de bases de datos se desvían a un receptor dedicado del equipo de DBA mediante expresiones regulares sobre la etiqueta de servicio. Los avisos de severidad intermedia generan tickets en Jira con un intervalo de agrupación mayor, del orden de treinta minutos, porque nadie necesita un ticket nuevo cada cinco. Y la telemetría informativa solo se emite dentro del horario laboral.
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 tentación de añadir rutas sin fin es real. Cada nueva ruta parece justificada en aislamiento, pero un árbol con treinta ramas se vuelve imposible de razonar. Revisarlo trimestralmente y podar lo que ya no aporta es un ejercicio más valioso que cualquier nueva regla.
Agrupación: el compromiso fundamental
La agrupación se controla con tres parámetros en tensión deliberada. El group_wait es el tiempo que espera antes de enviar la primera notificación de un grupo nuevo; valores bajos aceleran la detección pero fragmentan el mensaje. El group_interval marca cada cuánto se añaden alertas al grupo existente. El repeat_interval determina cada cuánto se reenvía un grupo ya notificado mientras siga activo.
Aquí está el compromiso central. Agrupar de forma agresiva reduce volumen y fatiga, pero puede retrasar la detección de síntomas que merecerían atención inmediata. Agrupar de forma fina 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. Es una herramienta infravalorada y la de mayor impacto durante incidentes regionales.
El patrón mental útil es distinguir entre alertas de causa y alertas de efecto. Las de causa describen el fallo raíz (el nodo se ha caído, la red se ha perdido, la base de datos no acepta conexiones). Las de efecto describen síntomas derivados. Quien está de guardia necesita ver las causas, no un listado de cincuenta efectos. Regla útil: 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 la herramienta 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 pagina, 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 mirar cuántas alertas han saltado, cuántas se han reconocido sin acción y 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.
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.
