You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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 arelabel_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:
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:
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
.The text was updated successfully, but these errors were encountered: