Grafana v13.1.0: new query builder for dashboard variables is a mess

It was always simple to create Query type dashboard variables:

{“find”: “terms”, “field”: “kubernetes_namespace.labels.deployment-name.keyword”}

Now, in v13 this clumsy query builder was introduced and it is no longer clear what we a re supposed to do with it.

You might thing that if you used query “{“find”: “terms”, “field”: “kubernetes_namespace.labels.deployment-name.keyword”}” in pre-v13 Grafana, then you could try something like this:

But alas, it only works partially because in addition to the legit deployment name values that the variable gets populated, I also get a generous bonus of trash values like “4583823” which apparently comes from document count value. And how can i get rid of this trash if the query builder INSISTS on having some kind of metric?

By the way, as an extra sucky part of grafana v13 - did you notice that when you switch from one Query Type tab to the other, the query that you wrote simply vanishes and if you didnt save it you have no other choice but to rewrite it manually? And not only that, but also if you are unfortunate enough to be compelled to select some other Metric, the same query that you tediously re-wrote vanishes again? I mean, this kind of degradation of a product is only possible when human quality control is not present

The trash numeric values come from doc_count leaking into variable results. Fix it by adding this in the Regex field of your variable editor:

/^(?!\d+$).+/

This filters out pure numeric values like 4583823. If your deployment names never consist of only numbers, this will work cleanly.


For numeric deployment try the Raw Data tab with your original query:

json

{"find": "terms", "field": "kubernetes_namespace.labels.deployment-name.keyword"}

This bypasses the Metrics tab entirely and should return clean values without needing regex at all.

yeah, i already tried the Raw Data tab and it doesnt work. My AI agent somehow managed to brute force the now legacy json query, perhaps utilizing some API trickery:

But as you see, there is a warning saying that this legacy thing will be removed in the future, so this is just a temporary workaround.

And as for regex filtering, in my case the deployment names are uniform and dont adhere to any pattern so it is really cumbersome to accommodate them all