Klickgesteuertes Grafana funktioniert, bis du zum ersten Mal eine zweite Kopie, ein Rollback oder eine Antwort auf „wer hat dieses Panel geändert?“ brauchst. Diese Anleitung zeigt, wie du Grafana aus Dateien statt per Klick betreibst, sodass du weißt, welchen Mechanismus du für welche Ressource nutzt, bevor du ein YAML schreibst.

Warum die UI zum Problem wird

Wenn Dashboards, Datenquellen und Alerts von Hand erstellt werden, geht im Lauf der Zeit dreierlei schief:

• Nichts ist reproduzierbar. Der Zustand lebt in Grafanas Datenbank. Eine Instanz neu aufzubauen bedeutet, jeden Klick zu wiederholen.
• Änderungen sind unsichtbar. Es gibt keinen Review-Schritt und keine Historie über das hinaus, was Grafanas eigenes Versionslog festhält.
• Umgebungen driften. Staging und Produktion weichen langsam voneinander ab, und niemand kann sagen, wie.

Die Lösung ist, die Datenbank als Cache und das Repository als Wahrheit zu behandeln. Alles, was Grafana braucht, wird entweder beim Start aus Dateien provisioniert oder von einem Werkzeug angewendet, das Dateien liest.

Die Schichten

Schicht	Format	Was sie steuert	Angewendet von
Server-Konfiguration	grafana.ini und GF_*-Umgebungsvariablen	Ports, Datenbank, Authentifizierung, SMTP, Logging, Feature-Toggles	Grafana beim Start
Provisioning von Datenquellen	YAML	Datenquellen und ihre Zugangsdaten	Grafana beim Start
Provisioning von Dashboards	YAML-Provider + JSON-Dateien	Dashboards und Ordner	Grafana, in einem Intervall neu gescannt
Provisioning von Alerting	YAML	Alert-Regeln, Contact Points, Policies, Mute Timings, Templates	Grafana beim Start
Provisioning von Plugins	YAML	Einstellungen für bereits installierte Plugin-Apps	Grafana beim Start
Terraform	HCL	Alles mit einer API: Ordner, Datenquellen, Dashboards, Alerts, Teams, Service Accounts	terraform apply
Grafana Operator	Kubernetes Custom Resources	Instanzen, Ordner, Dashboards, Datenquellen, Alert-Regeln	Ein Controller im Cluster
Git Sync	Eine Repository-Ressource	Dashboards in einem Git-Repository, in beide Richtungen synchronisiert	Grafana selbst

Welches solltest du nutzen?

• Ein Grafana in einem Container oder einer VM, kleines Team: Server-Konfiguration plus Datei-Provisioning. Es hat keine zusätzlichen beweglichen Teile.
• Kubernetes mit GitOps (Flux oder Argo CD): das Grafana-Helm-Chart für die Instanz, mit Provisioning-Dateien als ConfigMaps, oder der Grafana Operator, wenn du jedes Dashboard und jede Datenquelle als eigenes Kubernetes-Objekt willst.
• Viele Instanzen oder Grafana Cloud: Terraform, weil es auch Stacks, Service Accounts und Teams erstellen kann.
• Dashboards, die von vielen Leuten erstellt werden: Git Sync oder eine Code-Bibliothek wie das Grafana Foundation SDK, die das JSON erzeugt.

Diese lassen sich gut mischen. Ein gängiges Setup ist Datei-Provisioning für Datenquellen und Alerting, plus Git Sync oder Terraform für Dashboards.

Was Dateien nicht können

Manche Ressourcen haben kein Provisioning-Dateiformat. Plane dafür:

• Benutzer, Teams, Organisationen und Service Accounts werden über die API oder Terraform erstellt (oder einen Identity Provider mit SSO und Rollenzuordnung).
• Berechtigungen für Ordner und Dashboards werden über die API, Terraform oder den Operator verwaltet.
• Das erste Admin-Passwort wird nur beim ersten Start gesetzt, eine spätere Änderung braucht daher einen CLI- oder API-Aufruf.

Die Anleitungen zu Authentifizierung und Terraform behandeln die Workarounds.

Provisioniert heißt gesperrt

Provisionierte Ressourcen sollen Dateien gehören. Datenquellen können mit editable: false markiert werden, Dashboards aus einem Provider können UI-Speicherungen ablehnen, und provisionierte Alert-Ressourcen lassen sich in der UI gar nicht bearbeiten. Das ist der Punkt: Könnte jemand sie von Hand ändern, wäre Git nicht mehr die Wahrheit. Denk daran, dass die UI weiterhin nützlich ist, um Daten zu erkunden und ein Panel zu entwerfen, und der Authoring-Workflow in der Dashboards-Anleitung zeigt, wie du diese Entwürfe zurück in Git bringst.

Ein mentales Modell für eine Änderung

1. Bearbeite eine Datei im Repository (ein Dashboard-JSON, eine Datenquellen-YAML, eine Alert-Regel).
2. Öffne einen Pull Request, prüfe den Diff, merge.
3. Der Auslieferungsmechanismus wendet es an: ein Container-Neustart, ein Dashboard-Rescan, ein Flux-Abgleich oder terraform apply.
4. Grafanas eigene Datenbank wird aktualisiert, um zu passen. Geht etwas schief, nimm den Commit zurück.

Wie es weitergeht

Starte ein lokales Grafana aus einer Compose-Datei (nächste Anleitung), lerne die Konfigurationsregeln und füge dann Datenquellen, Dashboards und Alerts nacheinander hinzu. Als Referenz siehe die Grafana-Dokumentation.