Betrieb & Monitoring
Grafana
Grafana ist eine quelloffene Plattform zur Visualisierung von Metriken, Logs und Traces; sie fragt viele Datenquellen ab, speichert selbst keine Mess-/Logdaten.
- Dashboards über viele Datenquellen
- Visualisiert; eigene DB nur für Konfiguration
- Unified Alerting (Standard ab Grafana 9)
- Provisioning als Code (YAML/JSON)
- AGPLv3 (seit Grafana 8)
Grafana ist die verbreitete quelloffene Plattform, um Messdaten als Dashboards darzustellen. Entscheidend für das Verständnis: Grafana hält keine Mess-, Log- oder Trace-Rohdaten, sondern fragt zur Laufzeit konfigurierte Datenquellen ab und stellt deren Antworten dar. Eine eigene Datenbank nutzt Grafana nur für die Konfiguration, also Dashboards, Nutzer, Datenquellen und Alerting-Regeln. Fällt die Datenquelle aus, zeigt Grafana keine Messdaten; geht die Grafana-Datenbank verloren, sind Dashboards und Alarme betroffen, sofern sie nicht als Code provisioniert sind.
Dieser Artikel erklärt das Datenquellen-Prinzip, Panels und dynamische Dashboards mit Variablen, das Unified Alerting, das Provisioning als Code, die Einordnung im LGTM-Stack sowie die Lizenz-Historie von Apache 2.0 zu AGPLv3. Die Daten selbst liefern Systeme wie Prometheus (Metriken) oder Loki (Logs).
1. Datenquellen statt eigener Speicher
Grafana ist datenquellen-agnostisch. Es bindet eine Vielzahl von Quellen ein und stellt sie in derselben Oberfläche dar: Prometheus und InfluxDB/Graphite (Metriken), Loki (Logs), Tempo (Traces), Elasticsearch/OpenSearch, klassische SQL-Datenbanken (PostgreSQL, MySQL) sowie über ein Plugin auch Zabbix. Jede Quelle wird über ihre eigene Abfragesprache angesprochen (PromQL, LogQL, SQL).
Grafana hält keine Messdaten
Ein häufiges Missverständnis im Betrieb: „Grafana hat meine Metriken verloren.“ Hat es nicht, denn es speichert keine Mess- oder Logdaten. Grafana liest zum Zeitpunkt der Abfrage aus der Datenquelle; fehlt etwas, liegt das Problem an der Quelle (z. B. abgelaufene Retention in Prometheus). In seiner eigenen Datenbank hält Grafana dagegen sehr wohl Konfiguration: Dashboards, Nutzer, Datenquellen und Alerting-Regeln. Die gehören gesichert oder als Code provisioniert.
2. Panels, Dashboards und Variablen
Ein Dashboard besteht aus Panels (Graph, Tabelle, Gauge, Geomap und weitere). Variablen/Templating machen Dashboards dynamisch: Ein Dropdown im Kopf des Dashboards ändert einen Abfrageparameter für alle Panels gleichzeitig, etwa um zwischen Hosts oder Umgebungen zu wechseln. Transformationen erlauben Nachbearbeitung der Abfrageergebnisse (Joins, Filter, Berechnungen) direkt in Grafana, ohne die Datenquelle zu verändern.
3. Unified Alerting
Seit Grafana 9 ist das Unified Alerting der Standard: ein Alerting-System über alle Datenquellen hinweg. Alert Rules definieren Bedingungen über eine oder mehrere Quellen, Contact Points die Zielkanäle (E-Mail, Webhook, Slack, PagerDuty), Notification Policies das Label-basierte Routing, dazu Silences und wiederkehrende Stummschaltungen. Das alte Legacy-Alerting wurde mit Grafana 11 vollständig entfernt; Altbestände müssen vorher migriert sein.
4. Provisioning als Code
Für reproduzierbaren Betrieb werden Datenquellen, Dashboards, Alarme und Kontaktpunkte als Code verwaltet (YAML für die Konfiguration, JSON für Dashboards) und über das Provisioning-Verzeichnis oder neuere Git-Sync-Mechanismen eingespielt. Handgeklickte Dashboards ohne Versionierung sind in Infrastructure-as-Code-Setups ein Anti-Pattern, weil sie weder reviewbar noch wiederherstellbar sind.
Dashboards gehören in die Versionsverwaltung, nicht nur in die Datenbank der Grafana-Instanz. Erst als Code werden sie reviewbar, reproduzierbar und überstehen den Verlust einer Instanz.
5. LGTM-Stack und Lizenz
Grafana Labs pflegt einen kompletten Observability-Baukasten, den LGTM-Stack: Loki (Logs), Grafana (Visualisierung), Tempo (Traces) und Mimir (Langzeit-Metriken). Lizenzseitig stand Grafana bis Version 7 unter Apache 2.0; mit Version 8 (2021) wechselte der Kern auf AGPLv3. Für den reinen internen Betrieb ist das in der Regel unkritisch; wer Grafana modifiziert und als Dienst anbietet, sollte die Copyleft-Pflichten der AGPL prüfen. Grafana Enterprise ergänzt kommerziell unter anderem SAML, feingranulares RBAC, Reporting und bestimmte Datenquellen-Plugins.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Datenquellen-agnostisch: viele Quellen in einer Oberfläche | Keine eigene Datenhaltung; ohne funktionierende Quelle nutzlos |
| Mächtige, dynamische Dashboards über Variablen | AGPLv3 erfordert Prüfung bei Weitergabe als Dienst |
| Unified Alerting über alle Datenquellen hinweg | Einige Funktionen (SAML, granulares RBAC) nur in Enterprise |
| Provisioning als Code, reproduzierbare Instanzen | Migrationsaufwand bei großen Versionssprüngen (Alerting, Scenes) |
| Großes Ökosystem an Dashboards und Plugins | Visualisierung nur so gut wie die zugrunde liegende Datenqualität |
Häufige Fragen zu Grafana
Nein. Grafana ist ein Visualisierungs-Frontend und fragt externe Datenquellen zur Laufzeit ab. Die Daten liegen in Prometheus, Loki, einer Datenbank oder einer anderen Quelle, nicht in Grafana selbst.
Für den internen Eigenbetrieb in der Regel nicht. Relevant wird die AGPL erst, wenn man eine modifizierte Grafana-Version als Dienst für Dritte anbietet; dann greifen Offenlegungspflichten. Im Zweifel gehört das rechtlich geprüft.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Grafana im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.