Le testeur de routes Alertmanager qui montre quel récepteur correspond — avant qu’une astreinte ne soit déclenchée.

Pour tester le routing Alertmanager, collez votre arbre de routes (ou un alertmanager.yml complet — seul son bloc route est lu) ainsi que les étiquettes d’une alerte d’exemple. Le testeur reproduit le parcours d’Alertmanager dans votre navigateur et affiche quel récepteur ou quels récepteurs l’alerte atteindrait, le fil d’Ariane exact du chemin de route depuis la racine jusqu’au nœud correspondant, si un continue:true a fait déclencher plusieurs récepteurs, et le group_by effectif après héritage. C’est une simulation à blanc qui répond à la question « quel receiver correspond » sans envoyer la moindre notification.

amtool config routes test est la commande CLI officielle d’Alertmanager : vous lui passez un alertmanager.yml et un ensemble d’étiquettes, et elle imprime le récepteur correspondant. Ce testeur de routes Alertmanager en ligne fait la même chose dans le navigateur, sans binaire ni instance à installer — pratique pour déboguer rapidement les routes Alertmanager ou partager un cas reproductible. Là où amtool affiche le récepteur final, ce testeur montre en plus l’arbre de routing complet : le chemin parcouru, le comportement de continue et le group_by hérité.

La cause la plus fréquente est l’ordre à première correspondance : une route large placée au-dessus d’une route spécifique l’occulte, et l’alerte atterrit sur le mauvais récepteur. Viennent ensuite les regex non ancrées (un match_re partiel ne correspond pas) et les matchers Alertmanager mal formulés. Collez votre arbre et les étiquettes dans le testeur pour voir exactement quel receiver correspond et quel matcher a échoué — c’est la façon la plus rapide de déboguer des routes Alertmanager sans relancer une vraie alerte.

Par défaut, dès qu’une alerte correspond à une route dans une liste de frères, Alertmanager cesse de parcourir le reste de cette liste. Définir continue: true sur une route correspondante indique à Alertmanager de continuer à évaluer aussi les frères suivants, de sorte que l’alerte puisse atterrir dans plus d’un récepteur. C’est ainsi que les équipes répliquent chaque alerte critique vers un récepteur d’audit ou d’astreinte tout en l’acheminant vers l’équipe responsable. Le testeur affiche chaque récepteur produit par un continue, étiqueté pour que vous voyiez quelles correspondances proviennent d’une descente en cascade.

Oui, mais seulement via continue: true. Sans lui, l’ordre à première correspondance garantit qu’un seul récepteur se déclenche par liste de frères. Avec continue: true sur une route correspondante, l’alerte poursuit l’évaluation et peut atteindre plusieurs récepteurs. Le testeur liste chaque récepteur correspondant avec son chemin de route, ce qui permet de vérifier d’un coup d’œil combien de receivers une seule alerte déclenche réellement.

C’est précisément le but de cet outil : tester l’arbre de routing Alertmanager en ligne, sans serveur, sans amtool et sans instance Alertmanager active. Tout s’exécute à 100 % côté client. Votre arbre de routes et les étiquettes d’alerte sont analysés et évalués à l’intérieur de votre onglet de navigateur — rien n’est envoyé, et il n’y a ni compte ni inscription. Vous pouvez coller en toute sécurité des configurations internes, y compris des noms de récepteurs, des étiquettes de webhook quasi secrètes et des noms d’équipes privés.

Le visualiseur d’arbre de routing intégré à Alertmanager (côté Prometheus) montre la structure, mais il n’évalue pas vos étiquettes contre les matchers — il ne sait donc pas quelle route une alerte concrète emprunterait. Il ne tient pas non plus compte de l’ancrage des regex ni de l’ordre à première correspondance dans votre tête. Ce testeur va plus loin : collez de vraies étiquettes et il parcourt l’arbre de routing Alertmanager en ligne pour vous dire exactement quel nœud correspond et pourquoi, au lieu d’afficher seulement la forme de l’arbre.

Chaque alerte entre par la route racine, qui est le fourre-tout. À l’intérieur d’une route correspondante, les routes enfants sont évaluées de haut en bas et l’alerte descend dans le premier enfant dont tous les matchers Alertmanager sont vérifiés, puis continue dans ce sous-arbre. Si une route correspondante n’a aucun enfant correspondant, elle est la correspondance terminale et son récepteur se déclenche. La règle que l’on comprend souvent de travers est l’ordre à première correspondance : seul le premier frère correspondant est retenu, sauf si continue est défini. Le testeur rend cet ordre visible en affichant le chemin de route complet.