Grafana ist eine Open-Source-Plattform zum Visualisieren von und Alarmieren bei Metriken, Logs und Traces aus vielen Datenquellen. Die meisten begegnen ihr über die Web-Oberfläche, aber alles, was in einer Grafana-Installation zählt, lässt sich auch in Dateien beschreiben: Servereinstellungen, Datenquellen, Dashboards, Alert-Regeln, Contact Points und Notification Policies. Diese Reihe konzentriert sich auf diese zweite Arbeitsweise, sodass eine Grafana-Instanz jederzeit aus Git neu aufgebaut werden kann und sich niemand merken muss, was jemand letzten Monat angeklickt hat.

So funktioniert es

Grafana liest seine Konfiguration aus Schichten, die du kontrollieren kannst, ohne die UI zu öffnen:

1. Server-Konfiguration (grafana.ini und GF_*-Umgebungsvariablen) steuert Ports, Datenbank, Authentifizierung, SMTP und Feature-Toggles.
2. Provisioning-Dateien (YAML in einem Ordner provisioning/) erstellen beim Start Datenquellen, Dashboard-Provider, Alerting-Ressourcen und Plugin-Einstellungen.
3. Dashboard-JSON-Dateien auf der Platte werden von einem Dashboard-Provider geladen und während des Betriebs von Grafana neu gescannt.
4. APIs und Operatoren (Terraform, der Grafana Operator, Git Sync, die gcx-CLI) verwalten, was Dateien allein nicht können, etwa Teams, Service Accounts und Ordnerberechtigungen.

Weil all das reiner Text ist, passt es in denselben GitOps-Workflow wie der Rest deiner Infrastruktur, einschließlich Flux und Argo CD.

Kernkonzepte

• Datenquelle — eine Verbindung zu einem Backend wie Prometheus, Loki oder PostgreSQL. Dashboards und Alert-Regeln fragen Datenquellen per Name oder UID ab.
• Dashboard — ein JSON-Dokument aus Panels und Variablen. Grafana nutzt intern inzwischen ein neueres Dashboard-Schema, und älteres JSON wird beim Laden automatisch migriert.
• Ordner — organisiert Dashboards und Alert-Regeln und trägt Berechtigungen.
• Provisioning — Laden von Ressourcen aus Dateien beim Start, sodass sie existieren, bevor sich jemand anmeldet.
• Alerting — Alert-Regeln, Contact Points, Notification Policies, Mute Timings und Templates, die sich alle provisionieren lassen.
• Organisation — eine Mandantengrenze innerhalb eines Grafana-Servers; die meisten Dateien nehmen eine orgId.

Warum Grafana als Code betreiben

• Reproduzierbar. Eine verlorene oder neue Instanz kommt identisch aus dem Repository zurück.
• Prüfbar. Eine Änderung an Dashboard oder Alert ist ein Pull Request mit Diff und keine unverfolgte Bearbeitung.
• Konsistent über Umgebungen. Dev, Staging und Produktion teilen Definitionen und unterscheiden sich nur in Werten.
• Drift ist sichtbar. Provisionierte Ressourcen lassen sich gegen UI-Bearbeitungen sperren, sodass Git die Quelle der Wahrheit bleibt.

Erste Schritte

Starte Grafana in einem Container mit gemountetem Ordner provisioning/, füge eine Datenquellen-Datei und einen Dashboard-Provider hinzu und lege Dashboard-JSON daneben. Die folgenden Anleitungen beginnen dort und führen weiter zu Alerting, Secrets, Kubernetes, Terraform und dem Operator. Sie wurden gegen Grafana 13 geschrieben; prüfe die Grafana-Dokumentation für die Version, die du installierst, da einige „as code“-Funktionen noch als Alpha markiert sind.