[BUGFIX] prometheus: check for length of filters before adding braces

[coleenquadros]

Description

When metadata is used as a label matcher, it gets interpreted as a timeseries and does not return data since we dont add label matchers when defining the variable and forces the braces {} in the query.

      - kind: ListVariable
        spec:
          allowAllValue: false
          allowMultiple: false
          defaultValue: cloud
          display:
            hidden: false
            name: Label
          name: xyz_label_names
          plugin:
            kind: PrometheusLabelValuesVariable
            spec:
              datasource:
                kind: PrometheusDatasource
                name: rbac-query-proxy-datasource
              labelName: label_name
              matchers:
                - xyz_label_names{} >>> returns no data because of the braces

		dashboard.AddVariable("xyz_label_names",
			listVar.List(
				labelValuesVar.PrometheusLabelValues("label_name",
					dashboards.AddVariableDatasource(datasource),
					labelValuesVar.Matchers("xyz_label_names"),
				),
				listVar.DisplayName("Label"),
				listVar.DefaultValue("name"),
				listVar.AllowAllValue(false),
				listVar.AllowMultiple(false),
		

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

[AntoineThebaud]

Hello @coleenquadros can you add some context for this change in PR description please? Also the second commit doesn't seem related at all

[AntoineThebaud]

Could you move the changes related to the PieChart Go SDK to a separate PR please?

[AntoineThebaud]

Sorry I don't understand the issue you are trying to fix. The fact labelValuesVar.Matchers("xyz_label_names") generates the matcher xyz_label_names{} with empty braces is not a problem, in promQL querying metric_name is fully equivalent as querying metric_name{}. Just in case I checked if there could be any bug with the interpretation of empty braces on perses side & even the specific Prometheus API we use here but it's working as expected.

Thus please precise

• what payload you are submitting,
• what result you are currently getting,
• and what you would expect to have instead and why?

[jgbernalp]

@coleenquadros would be better to adjust the dashboard to use the label matchers like: https://github.com/rhobs/observability-operator/pull/1043/changes#diff-f0c52146637600f6ae740e23e9c7ccff866a1b45820f4171687689b3394c274dR154 ? In that case we won't need this patch that might be inconsistent with what is supported in the prometheus API. WDYT?

[coleenquadros]

In Grafana, the query is this resources/api/v1/label/label_name/values?limit=40000&start=1775548920&end=1775559780&match%5B%5D=xyz_label_names&max_source_resolution=auto when my variable query is this "query": "label_values(xyz_label_names, label_name)"

But when I use the plugin

labelValuesVar.PrometheusLabelValues("label_name",
			dashboards.AddVariableDatasource(datasource),
			labelValuesVar.Matchers("xyz_label_names"),
), 

would equate to in the CR

	     labelName: label_name
              matchers:
                - xyz_label_names{}