Zum Inhalt springen

Alertmanager Route Tester · Observability

Alertmanager Route Tester: sehen Sie, welcher Receiver greift — bevor er jemanden alarmiert.

Mit diesem Alertmanager Route Tester können Sie Ihr Alertmanager-Routing online testen: Fügen Sie einen Alertmanager-Routing-Tree und die Labels eines Beispiel-Alerts ein und durchlaufen Sie den Baum so, wie Alertmanager es tut — getroffene Receiver, den Routenpfad als Breadcrumb, das Verhalten von continue und die effektive Gruppierung. Sofort, in Ihrem Browser, ganz ohne laufende Instanz.

Läuft in Ihrem Browser — nichts, was Sie einfügen, verlässt diese Seite. Wie wir das belegen

Läuft in Ihrem Browser Keine Anmeldung Routing-genau Aktualisiert am 29.07.2026

Alertmanager Route Tester Playground

alertmanager.yml · route

Paste a route tree or full config — runs entirely in your browser.

alert labels · key=value

One label per line, e.g. severity=critical.

Tip: press Esc to release keyboard focus from an editor.

Matched receivers

Load an example or paste a route tree and an alert’s labels, then run to see which receiver(s) the alert reaches.

Die Lücke

Ein Routenbaum ist Code, den man nicht Schritt für Schritt durchgehen kann.

Eine Alertmanager-Route ist ein Entscheidungsbaum, und wie jeder Baum ist sie leicht subtil falsch zu konfigurieren: Eine breite Regel oberhalb einer spezifischen verdeckt diese stillschweigend, ein fehlendes continue verhindert, dass das Bereitschaftsteam je alarmiert wird, und eine nicht verankerte Regex trifft klammheimlich gar nichts.

Um zu sehen, welcher Receiver greift, lösen die meisten einen echten Alert aus und beobachten, wo er landet — langsam, laut und riskant in einem Live-Setup. Genau hier hilft es, Ihr Alertmanager-Routing zu debuggen, ohne etwas zu senden. Der eigene Routenbaum-Visualizer von Alertmanager unterstützt das, aber Sie müssen sich match vs. match_re vs. matchers, die First-Match-Reihenfolge und die Vererbung weiterhin im Kopf zusammenreimen. Siehe die offizielle route-Referenz und die matcher-Syntax.

Dieser Tester übernimmt den Durchlauf für Sie: Fügen Sie den Baum und eine Label-Menge ein, und er meldet den oder die Receiver, den ein Alert erreicht, samt vollständigem Pfad und effektiver Gruppierung — nichts installiert, nichts gesendet, nichts hochgeladen.

Sehen Sie die Routing-Regeln, die er modelliert, oder probieren Sie das Live-Playground oben aus.

Die Pipeline

So funktioniert es.

Fünf deterministische Schritte laufen bei jeder Auswertung von Anfang bis Ende durch — jedes Mal komplett in Ihrem Browser-Tab.

  1. Die Konfiguration parsen.

    Ihr YAML wird geparst und der Routenbaum aufgelöst — eine vollständige alertmanager.yml verwendet ihren route:-Block, ein bloßes route-Objekt wird als Wurzel genommen. Parse-Fehler werden gemeldet, nicht geworfen.

  2. Die Labels einlesen.

    Die key=value-Zeilen des Alerts werden zu einer Label-Menge. Ein fehlendes Label wird als leere Zeichenkette behandelt, genau so, wie Alertmanager es vergleicht.

  3. Den Baum durchlaufen.

    Beginnend an der stets treffenden Wurzel werden die Kindrouten der Reihe nach ausgewertet. Der Alert steigt in die erste passende Kindroute ab; ein continue: true hält die späteren Geschwister im Spiel.

  4. Die Vererbung auflösen.

    Bei jedem finalen Treffer werden der Receiver und die Felder für Gruppierung/Timer vom nächsten Vorfahren aufgelöst, der sie gesetzt hat — die Werte, die Alertmanager tatsächlich verwenden würde.

  5. Die Receiver anzeigen.

    Jeder Receiver, den der Alert erreicht, wird mit seinem Routenpfad als Breadcrumb, einer continue-Kennzeichnung wo relevant und dem effektiven group_by aufgeführt.

Routing-Regeln

Die 4 Regeln, die das Routing entscheiden.

Der Tester bildet diese Alertmanager-Semantik exakt nach — so können Sie Ihre Alertmanager-matchers online testen, statt zu raten. Jede der folgenden zeigt die Falle und die Lösung.

First Match gewinnt (außer bei continue)

Reihenfolge

Innerhalb einer getroffenen Route werden die Kinder von oben nach unten ausgewertet. Der Alert nimmt das ERSTE passende Geschwister und stoppt — spätere Geschwister werden übersprungen, sofern nicht continue: true gesetzt ist.

Falle

route
# Order matters — the broad rule above shadows the specific one
routes:
  - receiver: catch-all          # matches everything below
    matchers: ['severity=~".*"']
  - receiver: db-pager           # NEVER reached
    match: { service: database }

Lösung

route
# Specific first, broad last — or use continue
routes:
  - receiver: db-pager
    match: { service: database }
  - receiver: catch-all
    matchers: ['severity=~".*"']

continue: true → mehrere Receiver

Fan-out

Eine getroffene Route mit continue: true stoppt den Geschwister-Scan nicht, sodass der Alert auch in einer späteren Route landen kann. Nutzen Sie es, um kritische Alerts an einen Audit- oder Paging-Receiver zu spiegeln.

Falle

route
# Without continue, only the audit receiver fires —
# the owning team is never paged
routes:
  - receiver: all-critical-audit
    matchers: ['severity="critical"']
  - receiver: team-backend
    match: { team: backend }

Lösung

route
# continue: true lets BOTH fire
routes:
  - receiver: all-critical-audit
    matchers: ['severity="critical"']
    continue: true
  - receiver: team-backend
    match: { team: backend }

Regex sind vollständig verankert

matchers

Alertmanager umschließt jedes match_re und =~/!~-Muster als ^(?:…)$. Ein partielles Muster trifft niemals den gesamten Wert — eine häufige Ursache für „meine Route trifft nicht".

Falle

matchers
# 'staging' only matches the value EXACTLY "staging"
matchers:
  - env=~"staging"      # env=staging-eu does NOT match

Lösung

matchers
# Cover the rest of the value explicitly
matchers:
  - env=~"staging-.*"   # env=staging-eu matches

Gruppierung wird den Baum hinab vererbt

Gruppierung

group_by, group_wait, group_interval und repeat_interval fließen von einem Elternteil zu jeder Kindroute, die nichts Eigenes setzt. Das Blatt, das Sie sehen, ist womöglich nicht die Gruppierung, die gilt.

Falle

route
# This leaf has no group_by of its own…
route:
  group_by: ['alertname', 'cluster']
  routes:
    - receiver: db-pager
      match: { service: database }
      # …so it INHERITS [alertname, cluster]

Lösung

route
# Override only where the subtree needs it
route:
  group_by: ['alertname', 'cluster']
  routes:
    - receiver: db-pager
      match: { service: database }
      group_by: ['alertname', 'cluster', 'database']

Das vollständige Routing-Beispiel in der Alertmanager-Dokumentation — ein Wurzel-Receiver mit team-X- / team-Y- / database-Kindern — lädt als erstes Beispiel im Playground.

Weitermachen

Testen Sie den Rest Ihrer Alerting-Pipeline.

Routing ist der letzte Sprung. Bringen Sie die Labels an der Quelle in Ordnung — labeln Sie sie beim Scrapen um und weisen Sie nach, dass Ihre Alert-Regeln auslösen — und der Routenbaum oben hat die richtigen Labels, mit denen er arbeiten kann.

FAQ

Fragen, beantwortet.

Tippen Sie auf eine Frage, um die Antwort aufzuklappen.

Fügen Sie Ihren Routenbaum (oder eine vollständige alertmanager.yml — gelesen wird nur deren route-Block) und die Labels eines Beispiel-Alerts in den Route Tester ein. Das Tool bildet das Alertmanager-Routing in Ihrem Browser nach und zeigt, welcher Receiver greift, den genauen Routenpfad als Breadcrumb von der Wurzel bis zum getroffenen Knoten, ob ein continue:true mehrere Receiver auslöst und das effektive group_by, das der Knoten nach der Vererbung erhält. Es ist ein Trockenlauf des Dispatchings, ohne dass eine einzige Benachrichtigung gesendet wird.

amtool config routes test ist das offizielle CLI von Alertmanager, um zu prüfen, welchen Receiver eine bestimmte Label-Menge trifft — etwa amtool config routes test --config.file=alertmanager.yml severity=critical team=backend. Es liest dieselbe Konfiguration, die Alertmanager lädt, und gibt den oder die getroffenen Receiver aus. Dieser Route Tester macht dasselbe direkt im Browser: Sie brauchen kein installiertes amtool und keine geladene Konfiguration, um Ihr Alertmanager-Routing zu testen und zu sehen, welcher Receiver greift.

Fast immer steckt eine von drei Ursachen dahinter, wenn Sie ein Alertmanager-Routing debuggen: Eine breite Regel oberhalb einer spezifischen verdeckt diese still (First-Match), eine nicht verankerte Regex trifft den Wert nicht ganz, oder ein fehlendes continue lenkt den Alert in genau eine Route statt in mehrere. Fügen Sie den Routenbaum und die echten Labels in den Tester ein — der hervorgehobene Routenpfad zeigt sofort, an welchem Knoten der Alert anders abbiegt, als Sie erwartet haben.

Standardmäßig hört Alertmanager auf, den Rest einer Geschwisterliste zu durchsuchen, sobald ein Alert eine Route darin trifft. Setzt man continue: true an einer getroffenen Route, wertet Alertmanager auch die späteren Geschwister weiter aus, sodass der Alert in mehr als einem Receiver landen kann. So spiegeln Teams jeden kritischen Alert an einen Audit- oder Paging-Receiver, während er weiterhin an das verantwortliche Team geroutet wird. Der Tester kennzeichnet jeden Receiver, den ein continue erzeugt, sodass Sie sehen, welche Treffer durch das Durchfallen entstanden sind.

Ja — aber nur mit continue: true. Ohne dieses Flag verlässt ein Alert den Geschwister-Scan beim ersten Treffer und landet in genau einem Receiver. Mit continue: true an einer getroffenen Route werden auch spätere Geschwister ausgewertet, und der Alert kann mehrere Receiver gleichzeitig erreichen. Der Route Tester listet jeden getroffenen Receiver einzeln auf und markiert, welcher davon durch ein continue zustande kam.

Genau dafür ist dieser Route Tester gedacht. Er läuft zu 100 % clientseitig im Browser-Tab — Sie brauchen weder einen laufenden Alertmanager noch amtool, kein Konto und keine Anmeldung. Ihr Routenbaum und die Alert-Labels werden lokal geparst und ausgewertet, nichts wird hochgeladen. So können Sie interne Konfigurationen mit Receiver-Namen, Webhook-Labels und privaten Teamnamen bedenkenlos einfügen und Ihr Alertmanager-Routing testen, bevor Sie es ausrollen.

Ein Routing-Tree-Editor visualisiert die Struktur, wertet aber selten die volle Matching-Semantik aus, die Alertmanager tatsächlich anwendet: First-Match-Reihenfolge, vollständig verankerte Regex (^(?:…)$), den Unterschied zwischen match, match_re und matchers sowie die Vererbung von group_by und den Timern. Dieser Tester bildet genau diese Semantik nach und durchläuft den Baum mit Ihren echten Labels — wenn der Editor und die Realität auseinanderlaufen, zeigt der hervorgehobene Pfad, warum.

Jeder Alert betritt die Wurzelroute, die als Catch-all dient. Innerhalb einer getroffenen Route werden die Kindrouten von oben nach unten ausgewertet. Der Alert steigt in die erste Kindroute ab, deren Matcher alle zutreffen, und durchläuft diesen Teilbaum weiter. Hat eine getroffene Route keine passende Kindroute, ist sie der finale Treffer und ihr Receiver wird ausgelöst. Die am häufigsten falsch verstandene Regel ist Reihenfolge plus First-Match: Es zählt nur das erste passende Geschwister, sofern nicht continue gesetzt ist.

More free, private DevOps tools.

Der Alertmanager Route Tester ist eines von vielen Tools in OpsCanopy — einem wachsenden Schirm browserbasierter Validatoren, Konverter und Tester, die niemals einen Server berühren.

39 kostenlose Tools, jedes einzelne offlinefähig — opscanopy.com funktioniert ohne Registrierung, und nichts wird hochgeladen.

Verwandte Tools: der Prometheus Relabel Tester und der Loki Alert Rule Tester. Durchsuchen Sie das vollständige Tools-Verzeichnis.

Nicht verbunden mit, unterstützt von oder gesponsert durch das Prometheus-Projekt oder die Cloud Native Computing Foundation. Prometheus und Alertmanager werden hier ausschließlich beschreibend verwendet, um das Konfigurationsformat zu kennzeichnen, das dieses Tool prüft.