Grafana Templating & Variables Design Prompt

You are a senior SRE who has built reusable Grafana dashboards across many environments using templating.

I will provide:
- The dashboard purpose
- Current variable config
- Symptom (variable empty, dropdown slow, wrong values)

Your job:

1. **Variable types**:
   - **Query** — query data source for values
   - **Custom** — fixed list
   - **Constant** — fixed single value
   - **Datasource** — variable choosing DS
   - **Interval** — time interval picker
   - **Ad-hoc filters** — append to all queries
2. **For query variables**:
   - `label_values(metric, label)` — common pattern
   - `label_values({namespace="$ns"}, pod)` — chained
   - Sort, multi-value, "All" option
3. **For chained**:
   - One variable depends on another
   - `$parent` in child query
   - Cascading dropdowns
4. **For multi-value**:
   - `$var` expands to `regex_value`
   - Use in `=~` matchers: `pod=~"$pod"`
5. **For "All"**:
   - `.*` regex matches all
   - Or custom "All value" override
   - Can fan out queries massively
6. **For variable load time**:
   - Heavy queries slow dashboard load
   - Cache by setting `Refresh: On Dashboard Load`
   - Limit values via query
7. **For regex transformation**:
   - Regex field extracts subgroup
   - Useful for parsing label values
8. **For dynamic vs static**:
   - Static when values rarely change
   - Dynamic for production discovery

Mark DESTRUCTIVE: `All` with thousands of values, slow query variable refresh "On Time Range Change", regex matching nothing (empty dropdown).

---

Dashboard purpose: [DESCRIBE]
Variable config:
```
[PASTE]
```
Symptom: [DESCRIBE]

Why this prompt works

Variables enable reuse but have pitfalls. This prompt walks them.

How to use it

1. Pick type appropriately.
2. Chain when relationships exist.
3. Tune refresh for performance.
4. Test with multi-value + “All”.

Examples

Standard chained variables (cluster → namespace → pod)

# $cluster (query)
label_values(up, cluster)

# $namespace (query, depends on $cluster)
label_values(kube_pod_info{cluster="$cluster"}, namespace)

# $pod (query, depends on $cluster + $namespace, multi-value)
label_values(kube_pod_info{cluster="$cluster",namespace="$namespace"}, pod)

Variable in PromQL

# Single value:  pod="my-pod"
# Multi-value:   pod=~"pod-a|pod-b|pod-c"
# Use =~ for both:
sum by (pod)(rate(container_cpu_usage_seconds_total{cluster="$cluster",namespace="$namespace",pod=~"$pod"}[5m]))

Interval variable for binning

$__interval               # auto-adjusts to time range
# Variable: __interval
# Values: 1m, 5m, 10m, 30m, 1h
# Use in:
rate(metric[$__interval])

Datasource variable (multi-DS dashboard)

# Variable: ds
# Type: datasource
# Type filter: prometheus

# Use in panel query: source = $ds

Regex extract (custom value)

# Variable: $env
# Query: label_values(up, instance)
# Regex: /prod-(?<env>[a-z]+)/
# Extracts "env" group from instance name

Refresh modes

• Never — only on dashboard load (static-ish)
• On Dashboard Load — fresh each visit
• On Time Range Change — every range update (HEAVY)

Common findings this catches

• Variable empty → query returns no values; check.
• All fans out → restrict via query or custom “All” value.
• Dashboard slow because variable query → use Recording Rule for the variable source.
• Multi-value with = → only first matches; use =~.
• Chained variable not cascading → child query doesn’t reference parent.
• Interval variable in PromQL uses $__interval not $interval.
• Datasource variable with hardcoded DS in panel → broken switching.

When to escalate

• Org-wide dashboard standardization — strategic.
• Variable performance issues — recording rule design.
• Cross-DS templating — engineering.