Testar relabel_configs do Prometheus — antes que as suas regras descartem as suas métricas.

Os dois usam exatamente a mesma sintaxe e a mesma semântica de relabeling — o que muda é o estágio do pipeline em que rodam. relabel_configs roda antes do scrape, sobre os labels de descoberta de cada target (os __meta_*), e decide o que será scraped e com quais labels. metric_relabel_configs roda depois do scrape, sobre cada amostra já coletada, e é onde você descarta métricas barulhentas ou reescreve nomes. Como a semântica é idêntica, você pode colar qualquer um dos dois aqui: o mesmo engine trata os dois do mesmo jeito.

Cole uma lista YAML de regras em um painel e um ou mais conjuntos de labels de exemplo no outro, clique em Run e leia o resultado: os labels finais, quais foram adicionados, alterados ou removidos, e se o target inteiro foi descartado. É a forma mais rápida de confirmar que uma regra de relabel se comporta como você imagina antes de enviá-la para uma scrape config — sem precisar iterar contra um Prometheus ao vivo. Como tudo roda no navegador, você pode colar com segurança scrape configs internas com metadados privados.

Quase sempre por causa da regex totalmente ancorada. O Prometheus envolve cada regex de relabel como ^(?:sua-regex)$, então um keep só mantém o target se o valor de origem unido casar com o padrão inteiro, não só com uma parte dele. Uma regex de api NÃO casa com um valor de api-server, então o target cai. Cole as suas regras e os labels do target aqui: o tester aplica a mesma ancoragem, marca o target descartado e mostra a regra e a ação exatas que o removeram, para você ver por que o seu target do Prometheus está sendo descartado no relabel.

As duas decidem se a série será scraped ou armazenada, com base na regex ancorada aplicada à origem unida — mas em sentidos opostos. keep mantém o target apenas quando a regex casa e descarta todo o resto; drop faz o contrário: descarta quando a regex casa e mantém o resto. Um exemplo de relabel com keep e drop: use keep com regex no __name__ para guardar só um conjunto de métricas, ou drop com regex go_gc_.* para podar séries internas. As variantes keepequal e dropequal não usam regex — comparam a origem unida com o valor atual de target_label e decidem pela igualdade.

É o ponto e vírgula (";"). Quando uma regra lista vários source_labels, o Prometheus une os valores deles com o separator antes de aplicar a regex; se você não definir um separator, o padrão é ";". Então com source_labels: [job, instance] o valor unido fica algo como api;10.0.0.1:9090, e é esse texto que a regex precisa casar. O tester aplica o mesmo padrão, então você pode confirmar exatamente qual string a sua regex está vendo.

O hashmod une os source_labels com o separator, calcula o MD5 do resultado (o mesmo md5.Sum que o Prometheus usa), lê os últimos 8 bytes desse digest como um inteiro de 64 bits big-endian e armazena hash % modulus no target_label. Este tester reproduz exatamente essa receita, então os valores de shard que ele produz batem com o Prometheus byte a byte. Isso permite verificar uma configuração de sharding horizontal — hashmod para um label temporário, depois keep no shard que é seu — antes de colocá-la em produção.

Enquanto o replace opera sobre o valor de um label, o labelmap opera sobre os NOMES dos labels: para todo label cujo nome case com a regex, ele cria um novo label nomeado pelo replacement expandido, copiando o valor. É a clássica passagem de __meta_kubernetes_pod_label_(.+) para um label simples $1. As ações irmãs labeldrop e labelkeep também trabalham sobre nomes — labeldrop remove todo label cujo nome case; labelkeep remove todo label cujo nome NÃO case. O tester roda as três contra os nomes de label reais do seu conjunto.

Não. O tester roda 100% no lado do cliente. As suas regras de relabel e os conjuntos de labels são analisados e avaliados dentro da aba do seu navegador — nada é enviado para um servidor, e não há conta nem cadastro. Você pode colar com segurança scrape configs internas, incluindo metadados privados de targets e nomes de labels.