Description
Is your feature request related to a problem? Please describe.
It looks like the current behavior is to stop evaluating relabel matches after the first match is found. This deviates from the behavior in the Prometheus server relabel config processing where each rule is evaluated regardless of whether there is a prior match.
My goal is to reduce cardinality and memory leaks by using a flexible set of relabel rules that don't have to strictly match every possible route my nginx ingress handles.
Describe the solution you'd like
When multiple matches are defined in a relabel_config, evaluate each match and apply each replacement.
Describe alternatives you've considered
I also attempted to specify multiple relabel_configs for the same target label, but this causes an error:
panic: descriptor Desc{fqName: "nginx_http_response_count_total", help: "Amount of processed HTTP requests", constLabels: {}, variableLabels: [project request_uri <...>]} is invalid: duplicate label names
Additional context
An example:
I want to mask both UUIDs and dates found in a request path, so I'd like to be able to do something like this:
relabel_configs:
- target_label: 'request_uri'
from: 'request_uri'
matches:
# Mask UUIDs
- regexp: '(.*)([0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}|[0-9a-fA-F]{32})(.*)'
replacement: '${1}:UUID${3}'
# Mask YYMMDD date fields
- regexp: '(/.*/)(\d{6})(.*)'
replacement: '${1}:DATE${3}'
With the current behavior today, a request URI of /foo/2510b65b-9455-4309-b72c-a2d0f1fd0309/20241110/bar would return a label of /foo/:UUID/20241110/bar instead of /foo/:UUID/:DATE/bar.