Component(s)
Dashboards
What is missing? Please describe.
Description:
When generating Kubernetes dashboards (e.g., kubernetes-workload-ns-resources-overview, kubernetes-cluster-resources-overview) via community-mixins and applying them to a Perses instance connected to a local Prometheus Operator, the drop-down variables ($cluster, $namespace) show "No options," resulting in "No data" for all panels.
Root Cause Analysis:
Upon investigating the generated YAML and PromQL queries, I found two main factors breaking the out-of-the-box experience:
Strict job matchers in Variables:
The variable definitions hardcode specific job names in their matchers. For example:
labelName: cluster
matchers:
- up{job="kubelet"}
labelName: namespace
matchers:
- kube_namespace_status_phase{cluster="$cluster",job="kube-state-metrics"}
In many standard deployments (like kube-prometheus-stack or VMware Tanzu/VCF), the default job names often have prefixes (e.g., prometheus-kube-state-metrics). If the user does not explicitly override every job flag in main.go, the variables immediately fail to populate.
Strict dependency on the cluster label (Fails in Local TSDB):
The dashboards heavily rely on the cluster="$cluster" filter. However, in a single-cluster environment querying a local Prometheus, external_labels (where cluster is typically defined) are not written to the local TSDB. Since the local metrics lack the cluster label, the $cluster variable query fails, breaking the dependency chain for $namespace and all subsequent panels.
Steps to Reproduce:
-
Generate Kubernetes dashboards using go run main.go without explicit job override flags.
-
Apply the dashboards to Perses.
-
Connect Perses to a single-cluster local Prometheus (where metrics do not contain a cluster label in the local TSDB).
-
Observe that $cluster and $namespace variables fail to load ("No options").
Suggested Solutions/Enhancements:
For the job strictness: Consider loosening the variable matchers (e.g., removing the hardcoded job constraint for cluster discovery) or documenting the required CLI flags more prominently for users coming from kube-prometheus-stack.
For the single-cluster scenario: It would be highly beneficial to introduce a --single-cluster flag in main.go. This flag could generate a version of the dashboards that completely strips out the $cluster variable and the cluster="$cluster" PromQL filters, providing a seamless "plug-and-play" experience for local/single-cluster monitoring.
Environment:
Generated via: go run main.go from community-mixins
Prometheus deployment: Prometheus Operator
Describe alternatives you've considered.
No response
Environment Information
Environment
my-perses perses 1 2026-05-25 02:45:19.970287356 +0000 UTC deployed perses-0.21.0 v0.53.1
Generated via: go run main.go from community-mixins
Prometheus deployment: Prometheus Operator
Component(s)
Dashboards
What is missing? Please describe.
Description:
When generating Kubernetes dashboards (e.g., kubernetes-workload-ns-resources-overview, kubernetes-cluster-resources-overview) via community-mixins and applying them to a Perses instance connected to a local Prometheus Operator, the drop-down variables ($cluster, $namespace) show "No options," resulting in "No data" for all panels.
Root Cause Analysis:
Upon investigating the generated YAML and PromQL queries, I found two main factors breaking the out-of-the-box experience:
Strict job matchers in Variables:
The variable definitions hardcode specific job names in their matchers. For example:
In many standard deployments (like kube-prometheus-stack or VMware Tanzu/VCF), the default job names often have prefixes (e.g., prometheus-kube-state-metrics). If the user does not explicitly override every job flag in main.go, the variables immediately fail to populate.
Strict dependency on the cluster label (Fails in Local TSDB):
The dashboards heavily rely on the cluster="$cluster" filter. However, in a single-cluster environment querying a local Prometheus, external_labels (where cluster is typically defined) are not written to the local TSDB. Since the local metrics lack the cluster label, the $cluster variable query fails, breaking the dependency chain for $namespace and all subsequent panels.
Steps to Reproduce:
Generate Kubernetes dashboards using go run main.go without explicit job override flags.
Apply the dashboards to Perses.
Connect Perses to a single-cluster local Prometheus (where metrics do not contain a cluster label in the local TSDB).
Observe that $cluster and $namespace variables fail to load ("No options").
Suggested Solutions/Enhancements:
For the job strictness: Consider loosening the variable matchers (e.g., removing the hardcoded job constraint for cluster discovery) or documenting the required CLI flags more prominently for users coming from kube-prometheus-stack.
For the single-cluster scenario: It would be highly beneficial to introduce a --single-cluster flag in main.go. This flag could generate a version of the dashboards that completely strips out the $cluster variable and the cluster="$cluster" PromQL filters, providing a seamless "plug-and-play" experience for local/single-cluster monitoring.
Environment:
Generated via: go run main.go from community-mixins
Prometheus deployment: Prometheus Operator
Describe alternatives you've considered.
No response
Environment Information
Environment
my-perses perses 1 2026-05-25 02:45:19.970287356 +0000 UTC deployed perses-0.21.0 v0.53.1
Generated via: go run main.go from community-mixins
Prometheus deployment: Prometheus Operator