Prometheus relabel_configs testen — sehen Sie, was Ihre Regeln tun, bevor sie Metriken verwerfen.

Beide verwenden dieselbe Relabeling-Semantik — nur die Stufe in der Pipeline unterscheidet sich. relabel_configs läuft vor dem Scrape und entscheidet anhand der Discovery-Labels, welche Targets überhaupt gescrapt werden und mit welchen Labels. metric_relabel_configs läuft nach dem Scrape und arbeitet auf den eingelesenen Serien, etwa um teure Metriken zu verwerfen oder Labels zu bereinigen, bevor sie gespeichert werden. Dieselbe Engine in diesem Tester verarbeitet beide, weil Prometheus auf beide identische Regeln anwendet.

Sie fügen in einem Bereich Ihre relabel_configs als YAML-Liste ein und in den anderen einen oder mehrere Beispiel-Labelsätze, klicken auf Run und lesen das Ergebnis für jedes Target ab: die resultierenden Labels, welche hinzugefügt, geändert oder entfernt wurden, und ob das gesamte Target verworfen wurde. So können Sie Ihre Relabel-Regeln simulieren und bestätigen, dass sie sich wie erwartet verhalten, bevor Sie sie in eine echte Scrape-Konfiguration übernehmen — ohne ein laufendes Prometheus.

Meist, weil der Regex vollständig verankert ist. Prometheus umschließt jeden Relabel-Regex als ^(?:your-regex)$, das Muster muss also den gesamten zusammengefügten Quellwert treffen, nicht nur einen Teil davon — ein Regex von api passt NICHT auf api-server. Ein keep verwirft das Target, sobald die Quelle NICHT passt. Der Tester markiert jedes verworfene Target mit der verantwortlichen Regel und Aktion, sodass sofort sichtbar ist, warum ein Target verworfen wird. Verwenden Sie (.*) oder explizite Capture-Gruppen, wenn Sie einen Teilstring treffen wollen.

Ein einfaches Beispiel für keep und drop: keep verwirft das Target, es sei denn, die zusammengefügte Quelle passt auf den Regex; drop verwirft es genau dann, wenn sie passt. keep ist eine Whitelist (nur Treffer überleben), drop eine Blacklist (Treffer fliegen raus). Daneben gibt es keepequal und dropequal, die keinen Regex nutzen, sondern den zusammengefügten Quellwert mit dem aktuellen target_label-Wert vergleichen und bei Gleichheit behalten bzw. verwerfen. Beide Regelarten entscheiden, ob die Serie überhaupt gescrapt oder gespeichert wird.

Der Standard-Separator ist ein Semikolon (";"). Listet eine Regel mehrere source_labels auf, fügt Prometheus deren Werte mit diesem Separator zu einer einzigen Zeichenkette zusammen, bevor der Regex darauf abgeglichen wird. Sie können den separator pro Regel überschreiben. Der Tester verwendet exakt denselben Standard, sodass die zusammengefügte Quelle hier genau so aussieht wie in Prometheus.

hashmod fügt die Quell-Labels zusammen, bildet den MD5 des Ergebnisses (dasselbe md5.Sum, das Prometheus verwendet), liest die letzten 8 Bytes dieses Digests als 64-Bit-Integer in Big-Endian-Reihenfolge und speichert hash % modulus im Target-Label. Dieser Tester bildet genau dieses Verfahren nach, sodass die erzeugten Shard-Werte Byte für Byte mit Prometheus übereinstimmen. So verifizieren Sie ein horizontales Sharding-Setup — hashmod in ein temporäres Label, dann keep auf dem Shard, der Ihnen gehört —, bevor Sie es ausrollen.

labelmap operiert auf Label-NAMEN, nicht auf Werten. Es kopiert den Wert jedes Labels, dessen Name auf den Regex passt, in ein neues Label, das durch die expandierte Ersetzung benannt wird — die klassische Verschiebung von __meta_kubernetes_pod_label_(.+) zu einem einfachen Label namens $1. Verwandt sind labeldrop (entfernt jedes Label, dessen Name passt) und labelkeep (entfernt jedes Label, dessen Name NICHT passt). Der Tester führt alle drei gegen die tatsächlichen Label-Namen in Ihrem Satz aus.

Nein. Der Tester läuft zu 100 % clientseitig. Ihre Relabel-Regeln und Labelsätze werden in Ihrem Browser-Tab geparst und ausgewertet — nichts wird auf einen Server hochgeladen, und es gibt kein Konto und keine Anmeldung. Sie können bedenkenlos interne Scrape-Konfigurationen einfügen, einschließlich privater Target-Metadaten und Label-Namen.