Maybe you could store the matches in a readable file (e.g. YAML or just a plain text file), then write a simple tool to read this in and convert it to the long regexp.
On Tuesday, 15 November 2022 at 15:05:53 UTC [email protected] wrote: > Thank you Brian. > > That's definitely a more compact format, but the downside to that approach > is that it cannot be split up into multiple lines for readability since it > breaks YAML folding due to conversion of newlines to spaces. If using more > than a few matching blacklist expressions, tracking changes in a single > line becomes cumbersome. > > On Tuesday, November 15, 2022 at 9:41:03 AM UTC+2 Brian Candler wrote: > >> {__name__!~"(prefix_1|prefix_2).+"} >> >> On Tuesday, 15 November 2022 at 06:59:34 UTC [email protected] wrote: >> >>> Hello, >>> >>> I'm trying to find the best way to use federation to match a metric >>> blacklist. Currently we are using a single query string as one long array >>> element to accomplish this, i.e.: >>> >>> params: >>> 'match[]': >>> - >- >>> {__name__=~".+", >>> __name__!~"prefix_1.+", >>> __name__!~"prefix_2.+"} >>> >>> Breaking up this string into multiple elements does not work, as each >>> element is parsed into a separate match[] parameter in the HTTP >>> request. The response appears as if each array element was queried >>> individually and combined together after query execution, so one element >>> only excludes one prefix, the next element only excludes the next prefix, >>> etc. with the result that all matching timeseries are eventually returned. >>> >>> What is the recommend way to provide a query blacklist when federating >>> Prometheus servers? >>> >> -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/87d440b5-3db2-44a4-83eb-f011ccc5bf3en%40googlegroups.com.
