feat: make oneOf selectors respect regexes
feat: make oneOf selectors respect regexes
This was already supported when using these kind of selectors for dashboards or otherwise building queries, but it did not work for SLI aggregations.
In SLI aggregations, we used to break apart re:
selectors by
splitting them on |
. But not all of the selectors we use there are
straight up lists of things we want to select. This would break if we
specified a selector like re: '(prometheus|api_prom)_api_v1_.+'
.
To support this, we are now wrapping the array elements of a oneOf
selector in braces and keeping the entire value. For example:
{ job: { oneOf: ['hello.*', 'test_(prometheus|api_prom)_label'] } }
Will now result in a selector like this:
job=~"hello.*|(test_(prometheus|api_prom)_label)"
Notice the selector with a |
is wrapped in braces to signify it is a
single unit making it easier to track this down by grepping.
In the sli_metric_descriptor
, we now no longer escape the values
passed in as an re:
when normalizing them using oneOf
. '
This means that for an re:
that was an array, we'll select all of
the values matching any of the regexes.
{ job: { re: ['hello', 'world.*', 'prometheus_(this|that)_label'] } }
Will turn into
{ job: { oneOf: ['hello', 'world.*', 'prometheus_(this|that)_label'] } }
Which in turn will result in this selector:
job=~"hello|world.*|(prometheus_(this|that)_label)"
This means that we'll likely select too many values for SLI aggregations, because the same selector defined on a single SLI will turn in to:
job=~"hello", job="world.*", job="prometheus_(this|that)_label"
Obviously we wouldn't actually write that on a single SLI, but for SLI
aggregations that are generated from the sli_metric_descriptor
we
could be combining selectors for metrics that are used in different
SLIs on a single service.
This is correct, because the sli_aggregations:
selector should be
inclusive for all the selectors that could have been specified the
different SLIs.
This came to light in !7284 (diffs, comment 1897193671)
The changes in the different service definitions are embracing the
change of respecting regexes in oneOf
. Before we would manually
specify this as a regex. Which would still work correctly, but the
queries in mimir would look worse because we can't deduplicate the
separate pieces as they're just a string and we're not splitting them
by |
anymore. So by embracing the oneOf
in service definitions,
we can leave out repeated values.
The changes to the queries are therefore only the reordering of the elements in the joined regex to be alphabetically. Which I think is a good thing anyway.