Grafana InfluxDB (Flux/InfluxQL) Data Source Prompt

You are a senior observability engineer who has run Grafana against InfluxDB 1.x, 2.x, and 3.x.

I will provide:
- InfluxDB version and auth (token vs user/password)
- Buckets/measurements and tags/fields
- Panels or alerts to build

Your job:

1. **Pick the query language**: InfluxQL for 1.x (database + retention policy) or when the InfluxQL endpoint is enabled; Flux for 2.x org/bucket/token workflows.
2. **Configure auth**: token in `secureJsonData` for 2.x; user/password for 1.x; set org and default bucket.
3. **Flux queries**: use `from(bucket)` -> `range(start: v.timeRangeStart, stop: v.timeRangeStop)` -> `filter` -> `aggregateWindow(every: v.windowPeriod, fn: mean)` and `yield`.
4. **InfluxQL queries**: use `WHERE $timeFilter GROUP BY time($__interval)` with `fill(null)` and tag filters.
5. **Template variables**: build dropdowns with `SHOW TAG VALUES` (InfluxQL) or a Flux `schema.tagValues()` query.
6. **Downsampling**: align `aggregateWindow`/`GROUP BY time` to the dashboard interval to avoid overfetching raw points.
7. **Performance**: filter on tags (indexed) not fields, and avoid unbounded `range(start: 0)`.
8. **Provisioning**: express the datasource in YAML with the correct `version` (Flux vs InfluxQL) and secure token.

Mark DESTRUCTIVE: writing to the wrong bucket via a misconfigured datasource, exposing an all-access token, unbounded queries that overload the TSDB.

---

InfluxDB version/auth: [DESCRIBE]
Buckets/measurements/tags: [DESCRIBE]
Panels/alerts: [DESCRIBE]

Why this prompt works

InfluxDB has two query languages and three major versions with different auth models, and the single biggest source of broken Grafana panels is using the wrong one. This prompt makes the model commit to a version, choose Flux vs InfluxQL deliberately, and align windowing to the dashboard interval so queries stay cheap.

How to use it

1. State the version so the assistant picks Flux vs InfluxQL and the right auth.
2. List tags vs fields so it filters on indexed tags.
3. Describe the panel interval so aggregateWindow/GROUP BY time aligns.
4. Ask for a scoped token and provisioning YAML.

Useful commands

# Create a read-scoped token (InfluxDB 2.x CLI)
influx auth create --org myorg --read-bucket metrics --description grafana-ro

# Health-check the datasource via Grafana API
curl -s -H "Authorization: Bearer $GRAFANA_TOKEN" \
  http://localhost:3000/api/datasources/uid/influx-metrics/health

Example config

# provisioning/datasources/influxdb.yaml
apiVersion: 1
datasources:
  - name: InfluxDB Metrics
    type: influxdb
    uid: influx-metrics
    access: proxy
    url: http://influxdb:8086
    jsonData:
      version: Flux
      organization: myorg
      defaultBucket: metrics
      httpMode: POST
    secureJsonData:
      token: ${INFLUX_READ_TOKEN}

// Flux query: mean CPU by host, windowed to the dashboard interval
from(bucket: "metrics")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "cpu" and r._field == "usage_percent")
  |> filter(fn: (r) => r.host =~ /${host:regex}/)
  |> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
  |> yield(name: "mean")

-- Equivalent InfluxQL (1.x) with Grafana macros
SELECT mean("usage_percent") FROM "cpu"
WHERE ("host" =~ /$host/) AND $timeFilter
GROUP BY time($__interval), "host" fill(null)

Common findings this catches

• Wrong language errors → InfluxQL sent to a Flux datasource.
• TSDB overload → range(start: 0) unbounded scan.
• Slow queries → filtering on fields instead of tags.
• Overfetching → windowPeriod not aligned to interval.
• Broken dropdowns → wrong tag-values query for the version.
• Auth failures → token not scoped or in wrong field.
• Empty panels → measurement/field name mismatch.

When to escalate

• Migration from 1.x/2.x to 3.x — plan with the TSDB platform owner.
• Sustained TSDB load from dashboards — capacity and retention review.
• Token/secret management at scale — security and secret-store integration.