Prueba relabel_configs de Prometheus online — antes de que descarten tus métricas.

Ambos usan exactamente la misma semántica de relabeling; lo único que cambia es la etapa del pipeline en la que se aplican. relabel_configs se ejecuta antes del scrape, sobre los labels del target descubierto, y decide qué se scrapea y con qué labels. metric_relabel_configs se ejecuta después del scrape, sobre cada muestra ya recolectada, justo antes de almacenarla — útil para descartar series ruidosas. Como el motor es idéntico, este tester evalúa los dos igual: pega cualquiera de los dos bloques y verás el mismo comportamiento.

Pega una lista YAML de reglas en un panel y uno o varios conjuntos de labels de ejemplo en el otro, pulsa Ejecutar y lee el resultado para cada target: los labels resultantes, cuáles se añadieron, cambiaron o eliminaron, y si el target completo fue descartado. Es la forma más rápida de simular reglas relabel de Prometheus y confirmar que se comportan como crees antes de llevarlas a un scrape config — todo del lado del cliente, sin iterar contra un Prometheus en vivo.

Casi siempre es por el anclaje de la regex. Prometheus envuelve cada regex de relabel como ^(?:tu-regex)$, así que keep solo conserva el target si el valor de origen unido coincide con el patrón completo, no solo con una parte. Una regex keep de api NO coincidirá con un valor api-server, y el target se descarta. El tester aplica el mismo anclaje y marca cada target descartado con la regla y la acción responsables, así que ves al instante por qué Prometheus descarta tu target en lugar de adivinarlo. Usa (.*) cuando quieras coincidir con una subcadena.

Son opuestas. keep descarta el target salvo que el origen unido coincida con la regex; drop lo descarta cuando sí coincide. Ambas deciden si la serie se scrapea o se almacena siquiera. Sus parientes keepequal y dropequal no usan regex: comparan el valor de origen unido con el valor actual de target_label y mantienen o descartan según la igualdad. El tester etiqueta cada target descartado con la regla y la acción que lo eliminó.

El punto y coma (";"). Cuando una regla declara varios source_labels, Prometheus une sus valores con el separator antes de aplicar la regex, y ese separator vale ";" salvo que lo cambies explícitamente. Así, source_labels: [job, instance] sobre job=api e instance=10.0.0.1 produce la cadena api;10.0.0.1 para el match. El tester usa el mismo valor por defecto, por lo que el valor unido que ves coincide con el de Prometheus.

hashmod une los source_labels, calcula el MD5 del resultado (el mismo md5.Sum que usa Prometheus), lee los últimos 8 bytes de ese digest como un entero de 64 bits big-endian y almacena hash % modulus en el target_label. Este tester reproduce exactamente esa receta, así que los valores de shard que produce coinciden con Prometheus byte por byte. Eso te permite verificar una configuración de sharding horizontal —hashmod a un label temporal y luego keep sobre el shard que te corresponde— antes de desplegarla.

labelmap opera sobre los NOMBRES de los labels, no sobre sus valores. Para cada label cuyo nombre coincida con la regex, copia su valor a un nuevo label cuyo nombre es el reemplazo expandido — el clásico paso de __meta_kubernetes_pod_label_(.+) a un label plano $1. Es distinto de replace, que opera sobre el valor de un único label. El tester ejecuta labelmap (junto con labeldrop y labelkeep) contra los nombres de labels reales de tu conjunto para que veas qué nombres aparecen, se renombran o desaparecen.

No. El tester se ejecuta 100% del lado del cliente. Tus reglas de relabel y tus conjuntos de labels se analizan y evalúan dentro de la pestaña de tu navegador: no se sube nada a un servidor, y no hay cuenta ni registro. Puedes pegar con seguridad scrape configs internos, incluidos metadatos de targets privados y nombres de labels.