Metriken und Logdaten mit Grafana 13 visualisieren
Bessere Sicht
von Andreas Stolzenberger
Veröffentlicht in Ausgabe 10/2026 - PRAXIS
Wer bei der Echtzeit-Visualisierung von Metriken und Logdaten den Überblick verliert, riskiert im Ernstfall kritische Blindspots in der IT-Infrastruktur. Grafana steuert mit Version 13 gegen: Das neue Release führt das Unified-Storage-Backend ein, das sich vom klassischen SQL-Ansatz verabschiedet und den Weg für echte Grafana-as-Code-Workflows über Git-Sync ebnet. Aber auch die neuen Dynamic Dashboards sowie die automatisierten Pipelines via APIs heben Grafana auf eine höhere Stufe der Visualisierung.
Wenn es darum geht, Zahlenwerte wie Metriken grafisch in Echtzeit darzustellen, kommt Grafana zum Einsatz. Egal, ob es sich um CPU-Lasten, Temperaturen oder Luftfeuchtigkeit handelt: Die Anwendung bündelt Daten in Dashboards, wobei Anwender den Zeitrahmen von wenigen Minuten bis hin zu mehreren Jahren frei wählen können. Für die Visualisierung stehen Optionen wie Linien, Punkte, Kuchendiagramme und Tabellen zur Verfügung.
Andere Werkzeuge zur Visualisierung sind meist an einen größeren Softwarestack gebunden. Vor Jahren versuchte Influx mit Chronograf ein eigenes Dashboard für InfluxDB als Grafana-Alternative zu etablieren, das jedoch auf diese Datenquelle beschränkt blieb. Davon verblieb eine integrierte Benutzeroberfläche für InfluxDB 2, die Anwender primär zum Prüfen von Abfragen oder zur Kontrolle des Datenbestandes nutzen.
Hier liegt die Stärke von Grafana: Das Werkzeug ist modular aufgebaut und bietet für eine Vielzahl von Datenquellen passende Plug-ins. Neben Metriken visualisiert die Software Logdaten über Werkzeuge wie Loki. Dabei lassen sich neben den eigentlichen Loginhalten auch Fehlerraten grafisch aufbereiten. Aufgrund der Verbreitung existieren zunehmend Plug-ins für kommerzielle Umgebungen wie Hetzner Cloud, Dynatrace, Splunk, SAP Hana oder Snowflake. Grafana selbst bleibt Open Source, während der Hersteller Grafana Labs kommerzielle Support-Optionen und gehostete Instanzen anbietet.
Wenn es darum geht, Zahlenwerte wie Metriken grafisch in Echtzeit darzustellen, kommt Grafana zum Einsatz. Egal, ob es sich um CPU-Lasten, Temperaturen oder Luftfeuchtigkeit handelt: Die Anwendung bündelt Daten in Dashboards, wobei Anwender den Zeitrahmen von wenigen Minuten bis hin zu mehreren Jahren frei wählen können. Für die Visualisierung stehen Optionen wie Linien, Punkte, Kuchendiagramme und Tabellen zur Verfügung.
Andere Werkzeuge zur Visualisierung sind meist an einen größeren Softwarestack gebunden. Vor Jahren versuchte Influx mit Chronograf ein eigenes Dashboard für InfluxDB als Grafana-Alternative zu etablieren, das jedoch auf diese Datenquelle beschränkt blieb. Davon verblieb eine integrierte Benutzeroberfläche für InfluxDB 2, die Anwender primär zum Prüfen von Abfragen oder zur Kontrolle des Datenbestandes nutzen.
Hier liegt die Stärke von Grafana: Das Werkzeug ist modular aufgebaut und bietet für eine Vielzahl von Datenquellen passende Plug-ins. Neben Metriken visualisiert die Software Logdaten über Werkzeuge wie Loki. Dabei lassen sich neben den eigentlichen Loginhalten auch Fehlerraten grafisch aufbereiten. Aufgrund der Verbreitung existieren zunehmend Plug-ins für kommerzielle Umgebungen wie Hetzner Cloud, Dynatrace, Splunk, SAP Hana oder Snowflake. Grafana selbst bleibt Open Source, während der Hersteller Grafana Labs kommerzielle Support-Optionen und gehostete Instanzen anbietet.
Automatische Migration auf neues Datenformat
Die im Mai vorgestellte Version 13 von Grafana bringt strukturelle Änderungen mit sich. Unter anderem betrifft dies das Storage-Backend, das die Konfiguration und die Dashboards sichert. Während ältere Versionen eine Kombination aus SQL-Datenbank und regulären Dateien in einer Ordnerstruktur verwendeten, trennt sich Grafana 13 weitgehend von der SQL-Datenbank.
Das neue Backend läuft unter der Bezeichnung "Unified Storage" und nutzt eine reine Datei- und Ordnerstruktur, sodass die Anwendung besser mit Git zusammenarbeitet. Eine kleine SQLite-Datenbank für die Konfiguration des Diensts bleibt erhalten, allerdings ist der JSON-Code der Dashboards und Panels dort nicht mehr gespeichert.
Die Umstellung von Grafana 12.x auf Version 13 konvertiert die vorhandenen Daten automatisch. Anders als bei Systemen, die grundlegende Änderungen im Storage-Backend einführen, müssen Administratoren bei Grafana die Migration nicht manuell durchführen. Beim ersten Start der neuen Version übernimmt die Software die Konvertierung der Datenbank selbstständig. Zur Absicherung lässt sich vor dem Update ein Dump der Datenbank ausführen. In Testumgebungen mit einem Podman-Container über das offizielle Image "docker.io/grafana/grafana:latest" funktionierte die Umstellung ohne Datenverlust. Die Betriebssystem-Aktualisierung einer lokal installierten Variante via Paketmanager wurde nicht geprüft.
As-Code-Ansatz für Dashboards, Ordner und Alerts
Die wesentliche Neuerung der Version 13 ist die Funktion "Git-Sync", die in Version 12 als Technical Preview vorlag. Grafana gleicht damit Dashboard-Definitionen über Git ab, sodass sich Git-Workflows für die Infrastruktur nutzen lassen: IT-Verantwortliche entwickeln neue Dashboards als Code, pushen diese in ein Git-Repository und Grafana liest sie per Git-Pull ein.
Dieser Ansatz gewinnt durch KI-Modelle an Relevanz. Als Test ließen wir Claude Code ein Ansible-Playbook generieren, das einen Podman-Pod mit Victoria-Metrics- und Grafana-Containern bereitstellt. Ein zweites Playbook installierte die OpenTelemetry-Collector-Releases [1] auf Testservern. Die KI verfasste zudem die passenden Grafana-Dashboards und lud diese über Ansible in ein Git-Repository.
Da viele Admins ihre Dashboards interaktiv über das GUI erstellen, statt JSON-Code zu nutzen, erlaubt die Git-Sync-Funktion auch das Zurückschreiben lokaler Änderungen in das Git-Repository. Dergestalt bearbeiten Sie die Panels weiterhin über den visuellen Editor und beim Speichern führt Grafana im Hintergrund die Befehle "git commit" und "git push" aus.
Damit profitieren Sie von einem Infrastructure-as-Code-Ansatz, ohne den Code manuell zu editieren. Ein Git-Sync-Workflow lässt sich so aufsetzen, dass eine produktive Grafana-Instanz die Dashboards schreibgeschützt aus dem Main-Branch eines Git-Repositorys bezieht. Grafana-Admins entwickeln auf einer separaten Entwicklungsinstanz neue Dashboards und sichern diese in einen Development-Branch. Nach erfolgreichen Tests verschieben Sie das Dashboard in den Main-Branch, sodass es der produktiven Umgebung zur Verfügung steht.
Mehr Dynamik in den Ansichten
Bauen Sie Dashboards und Panels im WYSIWYG-Verfahren, bietet Ihnen Grafana neue Designwerkzeuge. Die Dashboard-Engine nutzt nun vorwiegend "Dynamic Dashboards", die zuvor ebenfalls im Technical-Preview-Status waren. Während sich einzelne Panels über Zeilen ("Rows") bereits länger ein- und ausklappen ließen, führt Version 13 gleichberechtigte "Tabs" ein. Diese Elemente lassen sich verschachteln, sodass Sie in einem Tab neue Rows erzeugen können und umgekehrt. Das hilft dabei, mehr selektierbare Informationen in ein Dynamic Dashboard zu integrieren, ohne die Ansicht zu überladen.
In älteren Versionen erstellten Admins häufig individuelle Metrikdashboards pro überwachtem Server. Das Netzwerk-I/O-Panel zeigte dabei beispielsweise die Transferraten aller LAN-Adapter in einer einzigen Grafik. Mit Tabs genügt ein einziges Dashboard, bei dem Sie über das Menü zwischen den Servern umschalten. Im Dashboard tauchen dann individuelle Panels pro LAN-Interface auf, aber nicht zwingend gleichzeitig. Über Rows blenden Sie einzelne Schnittstellen nach Bedarf ein oder aus.
Bild 1: Über Tabs lassen sich viele Panels in einem Dashboard verschachteln. Das Drop-down-Menü wählt den Server aus und die Tabs schalten zwischen den Metrik-Panels um.
Auch das Design der eigentlichen Panels hat sich vereinfacht. Im Edit-Modus lässt sich eine Seitenleiste ausklappen, die die Parameter des Panels anzeigt. Ein Multi-Preview zeigt verschiedene Panel-Stile basierend auf den echten Abfragedaten. Legen Sie beispielweise eine neue Liniengrafik für die CPU-Last an, zeigt das Panel im Edit-Modus neben der Liniengrafik, wie die Darstellung als Gauge oder als Kombination aus Wert und Linie aussehen würde.
Der Query-Editor verfügt zudem über einen grafischen Query-Builder für alte und neue Datenquellen. Für InfluxDB 2.x existiert weiterhin kein Flux-Query-Builder, für das System Victoria Metrics stellt Grafana hingegen einen Builder bereit, da dessen Abfragesprache MetricsQL eng an PromQL von Prometheus angelehnt ist.
Schritte der Migration zu Grafana 13
Das Update von Version 12 auf 13 konvertiert die SQL-Datenbank wie bereits angesprochen ohne Interaktion des Benutzers in das Unified-Storage-Backend. Auch bestehende Dashboards übernimmt die Aktualisierung ohne visuelle Änderungen als Dynamic Dashboards.
Um das Git-Sync-Feature zu verwenden, müssen Sie jedoch die Konfiguration anpassen. Viele Admins verwalten ihre Dashboards im Root-Verzeichnis von Grafana. Git ordnet diese jedoch in einer Unterverzeichnisstruktur ein und bevorzugt initial den Pull-Ansatz.
Für den Übergang exportieren Sie bestehende Dashboards als JSON-Dateien, kopieren diese in eine Git-taugliche Ordnerstruktur und pushen sie in ein Git-Repository. Anschließend richten Sie Git-Sync in Grafana ein.
Bild 2: Das neue Git-Sync gleicht Grafana-Dashboards bidirektional mit dem Git-Repository ab.
Sollen während der Übergangsphase sowohl die alten als auch die Git-gesynchronisierten Dashboards in der Konfiguration verbleiben, führt dies zu einem Konflikt, da jede UID eindeutig sein muss.
Vor dem Commit in das Git-Verzeichnis müssen Sie die UIDs im JSON anpassen:
{
"apiVersion": "dashboard.grafana. app/v2",
"kind": "Dashboard",
"metadata": {
"name": "iobroker",
"namespace": "default",
"uid": "xxxxxx",
Dabei sollten Sie veraltete Informationen aus dem Dashboard-JSON wie
entfernen, da auch die "deprecatedInternalID"nur einmal existieren darf. Git-Sync lässt sich über das GUI konfigurieren. Alternativ nutzt die Version 13 erweiterte Programmierschnittstellen.
Programmierschnittstellen nach Kubernetes-Vorbild
Bereits mit Version 12 hat Grafana begonnen, das REST-API nach dem Vorbild von Kubernetes auszubauen. Version 13 führt diesen Ansatz weiter und wechselt von der Struktur "/api/<funktion>/<instruktion>" zum modularen "/apis/<gruppe>/<funktion>/<instruktion>". Das Format der API-Payload orientiert sich an der YAML-Syntax von Kubernetes, sodass sich Erweiterungen von Drittanbietern in das API einklinken können. Der Infrastructure-as-Code-Ansatz beschränkt sich damit nicht mehr nur auf die Applikationsdaten wie Dashboards, sondern umfasst auch die Operation der Anwendung selbst.
Wir haben dies getestet und erstellten erneut mit Claude Code ein Ansible-Playbook, das die Git-Konfiguration des Grafana-Setups über das API einrichtete – das Ergebnis zeigt das Listing. Grafana adaptiert dafür eine YAML-Syntax nach dem Vorbild von Kubernetes.
Das Update der Major-Grafana-Version von 12 auf 13 verläuft ohne Unterbrechungen, obwohl sich im Kern die technische Infrastruktur ändert. Die umfangreiche Migration des Storage-Backends erfolgt automatisiert im Hintergrund. Lediglich für die Einführung der Git-Sync-Repositorys ist manueller Aufwand seitens der IT-Abteilung nötig, der schrittweise im laufenden Betrieb stattfinden kann.
Die konsequente Umsetzung des "as-Code"-Konzepts bei gleichzeitiger Verbesserung der UI-Werkzeuge zur Dashboardverwaltung überzeugt. Die erweiterten APIs ermöglichen es Administratoren, Managementprozesse über Werkzeuge wie Ansible oder mit Unterstützung von KI-Modellen vollständig zu automatisieren.