Tester les relabel_configs Prometheus — avant qu’ils n’abandonnent vos métriques.

Les deux appliquent des sémantiques de relabeling identiques ; seule l’étape du pipeline diffère. relabel_configs s’exécute avant le scraping : il agit sur les étiquettes de découverte de la cible et décide notamment si celle-ci est scrappée. metric_relabel_configs s’exécute après le scraping, sur chaque échantillon ramené, pour renommer, élaguer ou abandonner des séries individuelles. Comme le moteur est le même, vous pouvez simuler des règles relabel Prometheus pour l’un ou l’autre dans ce testeur sans rien changer.

Collez votre liste YAML de relabel_configs dans un volet et un ou plusieurs ensembles d’étiquettes d’exemple dans l’autre, puis appuyez sur Exécuter. Le testeur applique les règles exactement comme Prometheus et affiche, pour chaque cible, les étiquettes finales, celles qui ont été ajoutées ou réécrites, celles supprimées, et si la cible entière a été abandonnée. C’est le moyen le plus rapide de tester les relabel_configs Prometheus en ligne et de confirmer leur comportement avant de les livrer dans une configuration de scraping — sans itérer sur un Prometheus en production.

Une règle keep abandonne la cible sauf si la valeur source jointe correspond à la regex ancrée. Si votre cible disparaît, c’est presque toujours que la regex ne correspond pas à l’intégralité de la valeur : Prometheus encadre chaque motif sous la forme ^(?:votre-regex)$, donc une regex de api ne correspond PAS à api-server. Le testeur marque chaque cible abandonnée avec la règle et l’action responsables, ce qui répond directement à la question « pourquoi ma cible Prometheus est supprimée par le relabel » — utilisez (.*) autour du fragment recherché pour faire correspondre une sous-chaîne.

keep et drop sont symétriques. keep conserve la cible uniquement quand la source jointe correspond à la regex et l’abandonne sinon ; drop fait l’inverse : il abandonne la cible quand elle correspond. Un exemple de relabel keep/drop : keep avec regex: production ne garde que les cibles dont l’étiquette correspond à « production », tandis que drop avec la même regex supprimerait exactement ces cibles. Les deux décident si la série est scrappée ou stockée — collez les deux variantes dans le testeur pour voir le résultat opposé côte à côte.

Le séparateur par défaut est le point-virgule « ; ». Quand une règle liste plusieurs source_labels, Prometheus concatène leurs valeurs avec ce séparateur avant d’appliquer la regex. Par exemple, source_labels: [job, instance] sur job="api", instance="10.0.0.1:9090" produit la chaîne jointe api;10.0.0.1:9090. Vous pouvez le redéfinir avec le champ separator. Le testeur utilise la même valeur par défaut, vous voyez donc exactement la valeur jointe contre laquelle la regex est mise en correspondance.

hashmod joint les étiquettes source, calcule le MD5 du résultat (le même md5.Sum que celui utilisé par Prometheus), lit les 8 derniers octets de ce condensé comme un entier 64 bits big-endian, et stocke hash % modulus dans target_label. Ce testeur reproduit exactement cette recette, donc les valeurs de shard qu’il produit correspondent à Prometheus octet pour octet. Cela permet de vérifier un sharding horizontal — hashmod vers une étiquette temporaire, puis keep sur le shard que vous possédez — avant de le déployer.

labelmap agit sur les NOMS d’étiquettes, pas sur leurs valeurs. Pour chaque étiquette dont le nom correspond à la regex, elle crée une nouvelle étiquette nommée par le remplacement développé, avec la valeur de l’étiquette d’origine — c’est le classique passage de __meta_kubernetes_pod_label_(.+) vers une étiquette simple. À l’inverse, labeldrop supprime chaque étiquette dont le nom correspond, et labelkeep supprime celles dont le nom ne correspond PAS. Le testeur exécute les trois sur les noms d’étiquettes réels de votre ensemble.

Non. Ce testeur de relabeling Prometheus en ligne s’exécute à 100 % côté client. Vos règles de relabel et vos ensembles d’étiquettes sont analysés et évalués à l’intérieur de votre onglet de navigateur — rien n’est envoyé à un serveur, et il n’y a ni compte ni inscription. Vous pouvez donc coller en toute sécurité des configurations de scraping internes, y compris des métadonnées de cible privées et des noms d’étiquettes.