Häufige Fehler in Grafana-Abfragen: SQL, InfluxQL und Zeitfilter richtig verwenden

Wer mit Grafana arbeitet, stößt früher oder später auf Fehlermeldungen bei Abfragen – besonders dann, wenn Zeitfilter, Regex, GROUP BY oder LIMIT ins Spiel kommen. Der Grund: Grafana unterstützt unterschiedliche Datenquellen, die jeweils eigene Abfragesprachen und Regeln haben.

In diesem Beitrag zeige ich dir die häufigsten Fehlerquellen und erkläre, wie du Abfragen korrekt aufbaust – unabhängig von einer konkreten Domain oder Datenbank.

---

1. Warum LIKE oder =~ oft nicht funktionieren

Ein klassischer Fehler ist die Annahme, dass Grafana immer SQL verwendet. In Wirklichkeit hängt die Syntax vollständig von der Datenquelle ab:

Datenquelle	Sprache
MySQL / PostgreSQL	SQL
InfluxDB 1.x	InfluxQL
InfluxDB 2.x	Flux
Prometheus	PromQL

Beispiel eines fehlerhaften Ausdrucks

SELECT * FROM measurement WHERE time =~ '2025%'

❌ Problem:

• time ist kein String, sondern ein Timestamp
• Regex (=~) funktioniert nicht auf Zeitstempeln

---

2. Zeit richtig filtern: Der korrekte Weg

In Zeitreihen-Datenbanken wie InfluxDB wird Zeit immer über Bereiche gefiltert, nicht über String-Vergleiche.

Empfohlene Lösung (jahresbasierter Filter)

WHERE time >= '2025-01-01T00:00:00Z'
  AND time <  '2026-01-01T00:00:00Z'

✅ Vorteile:

• performant
• eindeutig
• kompatibel mit Grafana

---

3. Regex auf time → Warum das nicht geht

Ein häufiger Fehler ist die Verwendung von Regex auf das time-Feld:

WHERE time =~ /^2025/

❌ Führt zu:

invalid operation: time and RegexLiteral are not compatible

📌 Erklärung:

• Regex funktioniert nur auf Strings oder Tags
• time ist ein interner Timestamp

👉 Lösung: Zeiträume verwenden oder ein separates year-Tag speichern.

---

4. Dynamische Jahre mit Variablen kombinieren

In Grafana kannst du Dashboard-Variablen nutzen, um Jahre dynamisch zu setzen.

Beispiel mit Jahres-Variable

WHERE time >= '${year}-01-01T00:00:00Z'
  AND time <  '${year_plus_1}-01-01T00:00:00Z'

💡 Tipp:

• Variablen werden vor der Ausführung ersetzt
• String-Konkatenation passiert in Grafana, nicht in InfluxDB

---

5. ORDER BY + GROUP BY time() → ein häufiger Konflikt

Viele Fehler entstehen durch diese Kombination:

GROUP BY time(1d)
ORDER BY time DESC

❌ Problem:

• GROUP BY time() liefert bereits zeitlich sortierte Buckets
• ORDER BY ist redundant und kann Fehler verursachen

✅ Empfehlung:

• ORDER BY bei Zeitaggregation weglassen

---

6. Tagesdifferenzen korrekt berechnen

❌ Problematisch

SELECT difference(last(value))

• difference() gehört zu Flux, nicht zu InfluxQL

✅ Korrekt in InfluxQL

SELECT last(value) - first(value) AS daily_difference
FROM measurement
GROUP BY time(1d)

---

7. LIMIT mit GROUP BY – warum das oft scheitert

Ein besonders verwirrender Punkt:

GROUP BY time(1d)
LIMIT 10

❌ Fehler:

error parsing query: found LIMIT, expected ;

📌 Grund:

• InfluxQL erlaubt LIMIT nicht zuverlässig in Kombination mit GROUP BY time()

---

8. Saubere Alternativen zu LIMIT

✅ Lösung 1: Grafana-Panel begrenzen

• „Show last X points“
• empfohlener Weg für Dashboards

✅ Lösung 2: Subquery (falls unterstützt)

SELECT *
FROM (
  SELECT last(value) - first(value)
  FROM measurement
  GROUP BY time(1d)
)
LIMIT 10

✅ Lösung 3: Flux (InfluxDB 2.x)

|> aggregateWindow(every: 1d, fn: last)
|> difference()
|> limit(n: 10)

---

9. Best Practices für Grafana-Abfragen

✔ Nutze Zeitbereiche statt String-Filter
✔ Prüfe immer die Datenquelle & Abfragesprache
✔ Vermeide ORDER BY bei Zeitaggregation
✔ Verwende Grafana-Variablen für Dynamik
✔ Begrenze Ergebnisse lieber im Panel als in der Query

---

Fazit

Viele Grafana-Fehler sind keine Bugs, sondern Missverständnisse zwischen SQL, InfluxQL und Flux. Wer weiß,

• wie Zeit gespeichert wird
• welche Funktionen erlaubt sind
• und wo Grafana selbst filtert

spart Stunden an Debugging.