Claude Code & Grafana: Dashboards generieren, PromQL schreiben, Alerting verstehen

Grafana ist das Standardwerkzeug für Observability in modernen Infrastrukturen — aber wer zum ersten Mal ein leeres Dashboard öffnet, steht vor einer steilen Lernkurve. PromQL-Syntax, Panel-Typen, Datasource-Konfiguration, Alerting-Regeln, Provisioning über YAML: Das sind viele Konzepte auf einmal. Claude Code Grafana ist kein Zaubermittel, aber ein echter Beschleuniger: für Dashboard-JSON-Generierung, für PromQL-Queries, für Alert-Regeln und für Provisioning-Files, die man sonst mühsam aus der Dokumentation zusammenbaut.

Dieser Artikel zeigt, wie das konkret funktioniert — von den Grundlagen bis zu den praktischen Prompts, die Zeit sparen.

1. Was ist Grafana?

Grafana ist eine Open-Source-Plattform für Observability: sie visualisiert Metriken, Logs und Traces aus verschiedensten Quellen in interaktiven Dashboards. Die Kernidee ist die Trennung zwischen Datasource (woher kommen die Daten?) und Dashboard (wie werden sie angezeigt?). Das macht Grafana so flexibel — dieselbe Visualisierungslogik funktioniert egal ob die Daten aus Prometheus, InfluxDB oder einer PostgreSQL-Datenbank kommen.

Ein Grafana-Dashboard besteht aus Panels: einzelnen Visualisierungseinheiten die jeweils eine Query gegen eine Datasource ausführen und das Ergebnis als Graph, Gauge, Table oder einem der vielen anderen Panel-Typen darstellen. Über Variables und Templating kann man Dashboards dynamisch machen — zum Beispiel einen Dropdown für den gewünschten Server oder Service, der alle Panels gleichzeitig filtert.

2. Datasources: Prometheus, Loki, InfluxDB, PostgreSQL

Die vier häufigsten Datasources in der Praxis:

• Prometheus ist die Standard-Datasource für Infrastruktur-Metriken. Zeitreihen mit Labels, abgefragt per PromQL. Ideal für CPU, Memory, Netzwerk, Container-Metriken von Kubernetes.
• Loki ist Grafanas eigenes Log-Aggregationssystem — Prometheus für Logs. Abgefragt per LogQL. Stärke: sehr geringer Indexierungsaufwand, da nur Labels indexiert werden, nicht der Log-Inhalt selbst.
• InfluxDB ist eine spezialisierte Zeitreihendatenbank, die besonders gut für hochfrequente Sensordaten und IoT-Anwendungen passt. Abfragesprache: InfluxQL oder Flux (v2).
• PostgreSQL erlaubt SQL-Abfragen direkt in Grafana-Panels — nützlich für Business-Metriken aus bestehenden relationalen Datenbanken, ohne extra ETL-Pipeline.

Die Datasource-Konfiguration in Grafana ist in der UI einfach — aber wer mehrere Umgebungen (Dev, Staging, Production) verwaltet, landet schnell bei Provisioning als Code.

3. Panels, Visualisierungen und Variables

Grafana bietet eine große Auswahl an Panel-Typen: Time series für Zeitreihen, Gauge für einzelne Kennzahlen mit Schwellwert-Einfärbung, Stat für eine prominente Einzelzahl, Table für tabellarische Daten, Heatmap für Verteilungen über Zeit, Bar chart, Pie chart und viele weitere.

Besonders mächtig wird Grafana durch Variables: Template-Variablen die oben im Dashboard als Dropdown erscheinen und in allen Panel-Queries als $variable referenziert werden. Eine $host-Variable die aus Prometheus alle vorhandenen Host-Labels lädt, macht ein Dashboard mit einem Klick für jeden Server auswertbar — ohne ein Dashboard pro Server zu bauen.

4. PromQL-Grundlagen für Panels

PromQL ist die Abfragesprache für Prometheus. Die Grundkonzepte:

• Instant Vector: http_requests_total — der aktuelle Wert einer Metrik, optional gefiltert: http_requests_total{status="200", job="api"}
• Range Vector: http_requests_total[5m] — alle Samples der letzten 5 Minuten, wird für Funktionen wie rate() gebraucht
• rate(): rate(http_requests_total[5m]) — Anfragen pro Sekunde über ein 5-Minuten-Fenster, das wichtigste PromQL-Muster überhaupt
• Aggregation: sum(rate(http_requests_total[5m])) by (status) — summiert über alle Labels, gruppiert nach Status-Code

Transformations in Grafana erlauben es, Query-Ergebnisse nachzubearbeiten ohne die Query selbst zu ändern: Spalten umbenennen, Werte berechnen, mehrere Queries zusammenführen, nach Wert sortieren. Nützlich wenn die Datasource keine komplexen Berechnungen unterstützt oder wenn man Daten aus mehreren Quellen kombinieren will.

5. Alerting: Alert Rules, Contact Points, Notification Policies

Grafana Unified Alerting (seit Grafana 9 der Standard) trennt drei Konzepte sauber voneinander:

• Alert Rules definieren die Bedingung: welche Query, welcher Schwellwert, wie lange muss die Bedingung gelten bevor der Alert feuert (Pending Period). Eine Alert Rule hat immer eine Datasource, eine PromQL-Query oder SQL-Query, und eine Bedingung wie IS ABOVE 0.9.
• Contact Points definieren wohin Benachrichtigungen gehen: E-Mail, Slack, PagerDuty, Webhook, Telegram. Pro Contact Point kann man mehrere Integrationen konfigurieren.
• Notification Policies verbinden Alert Rules mit Contact Points über Label-Matching. Eine Policy sagt: "Alle Alerts mit severity=critical gehen an PagerDuty, alle anderen an Slack." So kann man Routing flexibel konfigurieren ohne jede Alert Rule einzeln zu verdrahten.

6. Provisioning als Code

Grafana unterstützt Provisioning über YAML- und JSON-Dateien im Verzeichnis /etc/grafana/provisioning/. Das bedeutet: Datasources, Dashboards und Alert-Konfiguration lassen sich als Code versionieren, in Git verwalten und per CI/CD deployen — ohne dass jemand in der UI herumklickt und Konfiguration verloren geht.

Eine Datasource-Provisioning-Datei sieht so aus:

# /etc/grafana/provisioning/datasources/prometheus.yaml
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false

Dashboard-Provisioning konfiguriert, aus welchen Verzeichnissen Grafana Dashboard-JSON-Dateien lädt:

# /etc/grafana/provisioning/dashboards/default.yaml
apiVersion: 1
providers:
  - name: default
    type: file
    options:
      path: /var/lib/grafana/dashboards

Das Dashboard-JSON selbst landet dann unter /var/lib/grafana/dashboards/. Änderungen am JSON werden beim nächsten Grafana-Start oder bei konfigurierten Update-Intervallen automatisch übernommen.

7. Claude Code Grafana: Konkrete Tipps

Hier liegt der eigentliche Mehrwert: Grafana-Konfiguration ist viel JSON und YAML — genau das, was Claude Code schnell und korrekt generiert, wenn man die Anforderungen klar beschreibt.

Dashboard-JSON generieren

Statt stundenlang in der UI zu klicken, kann man Claude Code ein vollständiges Dashboard-JSON generieren lassen:

claude "Erstelle ein Grafana Dashboard JSON für eine Node.js API.
Panels: Request Rate (rate über 5m), Error Rate (4xx+5xx),
P99 Latenz, aktive Verbindungen. Datasource: Prometheus.
Variable: $service mit Label-Werten von job-Label."

Das Ergebnis ist ein valides Dashboard-JSON, das man direkt in Grafana importieren oder ins Provisioning-Verzeichnis legen kann.

PromQL-Queries schreiben

claude "Ich habe eine Prometheus-Metrik http_request_duration_seconds
als Histogram. Schreib mir die PromQL-Query für das 95. Perzentil
der Latenz, gruppiert nach dem Label 'endpoint', über 10 Minuten."

Claude Code kennt die PromQL-Syntax für histogram_quantile(), die notorisch tricky zu schreiben ist wenn man sie selten braucht — und gibt die fertige Query zurück, die man direkt ins Panel einfügen kann.

Alert-Regeln erklären und bauen

claude "Erkläre mir den Unterschied zwischen einer Alert Rule
mit Pending Period 0 und einer mit 5 Minuten. Wann ist was sinnvoll?"

Oder direkt eine Alert Rule als YAML generieren:

claude "Erstelle eine Grafana Alert Rule als YAML: CPU über 80%
für mehr als 5 Minuten, gefeuert an Contact Point 'ops-slack',
mit Labels severity=warning und team=infrastructure."

Provisioning-Files bauen

claude "Erstelle alle nötigen Grafana Provisioning YAML-Files
für folgendes Setup: Prometheus als Default-Datasource auf
localhost:9090, Loki auf localhost:3100, und lade Dashboards
aus /dashboards/. Ich nutze Grafana 10."

Claude Code generiert die korrekten Dateistrukturen für die jeweilige Grafana-Version — wichtig, weil sich die Provisioning-API zwischen Versionen leicht unterscheidet.

Verwandte Artikel, die auf diesem Thema aufbauen:

• Claude Code & Prometheus — Metriken definieren, Exporter konfigurieren, Recording Rules verstehen
• Claude Code Debugging — wie Claude Code Logs analysiert und Root-Causes findet