Probador de rutas de Alertmanager: ve a qué receiver llega una alerta antes de que avise a nadie.

Pega tu árbol de rutas (o un alertmanager.yml completo —solo se lee su bloque route—) y las etiquetas de una alerta de ejemplo en este probador de rutas de Alertmanager. Reproduce el recorrido de enrutamiento en tu navegador y te muestra qué receiver o receivers alcanzaría la alerta, la ruta exacta —el breadcrumb— desde la raíz hasta el nodo coincidente, si un continue:true hizo que se dispararan varios receivers, y el group_by efectivo con el que termina ese nodo tras la herencia. Es un simulacro del dispatch sin enviar una sola notificación.

amtool config routes test es el comando oficial para probar el enrutamiento de Alertmanager desde la CLI: le pasas un conjunto de etiquetas y te dice a qué receiver llegaría esa alerta según tu configuración. Es la misma idea que este tester, pero amtool necesita el binario instalado y el archivo a mano, mientras que aquí pegas el árbol de routing de Alertmanager online y obtienes el resultado en el navegador, sin instalar nada. Úsalo para depurar las rutas de Alertmanager rápido y luego confirma con amtool en CI si lo prefieres.

Casi siempre es por el orden y el first-match. Dentro de una ruta coincidente, los hijos se evalúan de arriba abajo y solo se toma el primer hermano cuyos matchers se cumplen todos —salvo que se haya puesto continue: true—. Una regla amplia colocada encima de una específica la deja en sombra, y la alerta acaba en el receiver equivocado. La otra causa frecuente es una regex sin anclar: match_re y =~ se anclan por completo, así que staging no coincide con staging-eu. Pega el árbol y las etiquetas en el tester para ver qué receiver coincide de verdad y por qué ruta.

Por defecto, una vez que una alerta coincide con una ruta dentro de una lista de hermanos, Alertmanager deja de escanear el resto de esa lista. Establecer continue: true en una ruta coincidente le indica a Alertmanager que siga evaluando también los hermanos posteriores, de modo que la alerta pueda aterrizar en más de un receiver. Es la forma en que los equipos replican cada alerta crítica hacia un receiver de auditoría o de paging mientras la siguen enrutando al equipo propietario. El tester muestra cada receiver que produce un continue, etiquetado para que veas qué coincidencias provienen de la caída en cascada.

Sí, pero solo si usas continue: true. Sin él, Alertmanager se detiene en el primer hermano coincidente y la alerta llega a un único receiver. Con continue: true en una ruta coincidente, el escaneo continúa por los hermanos posteriores y la misma alerta puede aterrizar en varios receivers a la vez —por ejemplo, en el equipo propietario y en un receiver de auditoría—. Este probador de árbol de routing de Alertmanager lista cada receiver que alcanza la alerta, así ves de un vistazo cuándo una alerta se reparte entre varios.

No necesitas un Alertmanager corriendo ni el binario amtool. Este tester es 100% del lado del cliente: pega el bloque route (o el alertmanager.yml entero) y las etiquetas de la alerta, y evalúa el árbol dentro de la pestaña de tu navegador. Tu árbol de rutas y las etiquetas no se suben a ningún sitio, y no hay cuenta ni registro. Puedes pegar con seguridad configuraciones internas, incluidos nombres de receivers, etiquetas de webhooks con aspecto de secreto y nombres de equipos privados, para depurar las rutas de Alertmanager en local.

Suele ser por dos detalles de la semántica de Alertmanager que un visualizador estático no aplica. Primero, la herencia: group_by, group_wait, group_interval y repeat_interval fluyen desde un padre hacia cualquier hijo que no establezca el suyo, así que la hoja que ves puede no reflejar la agrupación real. Segundo, el anclaje de las regex: match_re y =~ se envuelven como ^(?:…)$, de modo que una coincidencia parcial nunca cuenta. Este tester resuelve la herencia y ancla las regex igual que Alertmanager, por eso la ruta que muestra coincide con la que se aplicaría en producción.

Toda alerta entra por la ruta raíz, que es el catch-all. Dentro de una ruta coincidente, las rutas hijas se evalúan de arriba abajo y la alerta desciende hacia el primer hijo cuyos matchers se cumplen todos, siguiendo por ese subárbol. Si una ruta coincidente no tiene ningún hijo que coincida, esa ruta es la coincidencia terminal y se dispara su receiver. La regla clave que la gente confunde es el orden más el first-match: solo se toma el primer hermano coincidente, salvo que se haya establecido continue. Recuerda que match es igualdad exacta, match_re y matchers (severity="critical", env=~"prod-.*", team!="frontend") combinan igualdad, desigualdad y regex anclado, y una ruta solo coincide cuando se cumplen todas las cláusulas.