Aussagekräftige Grafana-Dashboards

Aussagekräftige Grafana-Dashboards

0:00 Dashboards sind das Aushängeschild jeder Observability-Einführung — und gleichzeitig die Stelle, an der am meisten Aufwand verpufft. Grafana selbst formuliert den Anspruch erfreulich klar: Ein Dashboard soll eine Geschichte erzählen oder eine Frage beantworten. Alles andere ist eine Bildergalerie. In diesem Modul geht es deshalb weniger um Panel-Typen als um die Frage, was überhaupt auf ein Dashboard gehört — und was besser nicht.

0:25 Am Ende bauen Sie eines für Pfandwerk und halbieren ein anderes.

Aussagekräftige Grafana-Dashboards

0:29 Drei Kapitel. Zuerst der Zweck: Für wen ist dieses Dashboard, und welche Frage beantwortet es? Dann Aufbau und Wiederverwendung, wo Variablen die zentrale Rolle spielen. Und drittens die Antipatterns, die Grafana ausdrücklich benennt — die lohnen einen ehrlichen Abgleich mit dem eigenen Bestand. In der Übung entsteht ein Service-Dashboard aus den Abfragen von Modul dreizehn.

Zweck vor Panel

0:53 Fangen wir mit der Frage an, die man sich vor dem ersten Panel stellen sollte und die fast nie gestellt wird: Wer wird das ansehen, und was will diese Person wissen? Die Antwort bestimmt alles Weitere — Auswahl, Reihenfolge, Detailgrad, sogar die Farben. Ohne sie entsteht zuverlässig ein Dashboard, das viel zeigt und wenig beantwortet.

1:13 Grafana formuliert den Anspruch in zwei Teilen. Erstens: Ein Dashboard soll eine Geschichte erzählen oder eine Frage beantworten, mit einer logischen Abfolge der Daten — von groß nach klein, von allgemein nach speziell. Zweitens: Es soll die geistige Last des Betrachters senken, nicht erhöhen. Dieser zweite Satz ist ein guter Prüfstein.

1:33 Nehmen Sie eines Ihrer Dashboards und fragen Sie, ob jemand nach fünf Sekunden weiß, ob alles in Ordnung ist. Wenn nicht, erhöht es die Last, statt sie zu senken. Diese Schichtung löst ein Problem, das viele Teams mit einem einzigen Dashboard zu lösen versuchen — und daran scheitern. Die Übersicht beantwortet: Geht es dem Angebot gut, und seit wann nicht? Das Service-Dashboard: Wie steht ein einzelner Dienst da, nach dem RED-Satz aus Modul zwölf?

2:01 Das Diagnose-Dashboard: Wo genau bricht es, mit Absprüngen in Trace und Log. Drei Zielgruppen, drei Detailgrade. Wer alles in eines packt, bekommt ein Dashboard, das für jede Zielgruppe zu viel und zu wenig zeigt. Vier Punkte. Die Bereitschaft braucht eine Antwort in fünf Sekunden, nicht dreißig Diagramme — im Zweifel eine einzige große Zahl.

2:23 Das Fachteam fragt nach Vorgängen, nicht nach Heap-Auslastung. Ein Panel ohne zugeordnete Frage kostet Platz und Aufmerksamkeit; und Aufmerksamkeit ist die knappste Ressource im Störfall. Und der vierte Punkt ist eine Empfehlung aus der Dokumentation, die man selten befolgt: Die Überwachungsstrategie gehört schriftlich festgehalten.

2:42 Dann kann man neue Dashboards dagegen prüfen, statt sie einzeln zu diskutieren. Der erste Punkt ist der Normalfall in gewachsenen Umgebungen: Das Dashboard zeigt alles, was die Datenquelle hergibt. Das entsteht nicht aus Absicht, sondern aus Bequemlichkeit. Der zweite ist handwerklich und wird nie bemerkt, bis jemand die falsche Entscheidung trifft: fehlende Einheiten.

3:05 Der dritte sind zufällige Farben statt bedeutungstragender — Grafana empfiehlt ausdrücklich, dass Farben etwas heißen sollen. Und der vierte ist die Panel-Reihenfolge, die der Entstehung folgt statt dem Analyseweg. Der Analyseweg steht bei Ihnen seit Modul fünfzehn fest.

Aufbau und Wiederverwendung

3:21 Jetzt zum handwerklichen Teil — und zum wirksamsten Mittel gegen den Wildwuchs, den fast jede Grafana-Installation nach zwei Jahren aufweist. Das Mittel heißt Variable, ist erstaunlich einfach zu verwenden und wird trotzdem selten eingesetzt, weil Kopieren im Moment schneller geht. Wir schauen uns außerdem an, welche Darstellungsform zu welcher Fragestellung passt.

3:42 Variablen ersetzen die Vervielfältigung: Statt je Dienst oder je Umgebung ein eigenes Dashboard anzulegen, führen Sie eine Variable ein, und das Dashboard bleibt eines. Besonders nützlich ist ein Detail, das viele nicht kennen — auch die Datenquelle selbst kann eine Variable sein. Damit läuft dasselbe Dashboard gegen Test und Produktion, ohne dass Sie es kopieren müssen. Für Pfandwerk heißt das: ein Dashboard für vierzig Filialen statt vierzig Dashboards.

4:09 Der Unterschied im Pflegeaufwand ist gewaltig. Die Logik ist, dass die Form der Frage folgt. Verläufe über die Zeit gehören in eine Zeitreihendarstellung — Rate, Fehlerquote, Latenz. Eine Verteilung über die Zeit, also das Histogramm aus Modul vierzehn, zeigt eine Heatmap besonders gut. Zustandswechsel, etwa die Verfügbarkeit je Filiale, gehören in eine Zeitleiste. Und Rangfolgen mit Details gehören in eine Tabelle — die zehn langsamsten Vorgänge zum Beispiel.

4:38 Die Fußzeile ergänzt einen Strukturhinweis aus der Dokumentation: Reihen je Dienst, geordnet nach Datenfluss, bilden Ihre Architektur im Dashboard ab. Vier Punkte, die den Lebenszyklus beschreiben. Eine Korrektur muss nach dem Kopieren an vierzig Stellen nachgezogen werden — was niemand tut. Dann weiß niemand mehr, welche Kopie gilt. Kopierte Schlagworte verfälschen zusätzlich die Suche, weil plötzlich vierzig Treffer erscheinen.

5:05 Und der vierte Punkt ist eine konkrete Empfehlung aus der Dokumentation: Vorübergehende Dashboards gehören gekennzeichnet und danach gelöscht. Ein Präfix genügt — und dann eine Aufräumrunde, die sich an diesem Präfix orientieren kann. Der erste Punkt ist das Dashboard je Filiale, über das wir gerade gesprochen haben. Der zweite ist die halbe Umsetzung: Die Variable existiert, aber ein Panel filtert weiterhin fest — und das fällt erst auf, wenn jemand umschaltet und sich ein Panel nicht ändert.

5:34 Der dritte ist ein Betriebsthema: Aktualisierungsraten im Sekundenbereich belasten den Prometheus-Server erheblich, ohne dass jemand die Daten in dieser Frequenz liest. Und der vierte ist eine verpasste Gelegenheit — fehlende Absprünge in Trace und Log, sodass die Analyse im Dashboard endet.

Antipatterns vermeiden

5:51 Jetzt zum unangenehmen Teil: der ehrlichen Durchsicht des eigenen Bestands. Grafana benennt drei Antipatterns ausdrücklich, und alle drei entstehen nicht aus Nachlässigkeit, sondern weil sie im Moment bequem sind. Die vierte Empfehlung ist die unbeliebteste von allen und gleichzeitig die wirksamste: regelmäßig aufräumen und Überflüssiges löschen.

6:11 Drei Antipatterns stehen ausdrücklich in der Dokumentation. Gestapelte Kurven, die wichtige Informationen verdecken können — dazu gleich mehr. Überhöhte Aktualisierungsraten. Und die unkontrollierte Vermehrung durch Kopieren. Dazu kommt die regelmäßige Durchsicht mit dem Ziel, Überflüssiges zu entfernen. Das klingt nach Hausputz und ist tatsächlich die wirksamste Maßnahme: Ein Dashboard weniger senkt die Last auf dem Server und die Last im Kopf gleichzeitig.

6:40 Diese Gegenüberstellung ist als Selbsttest gedacht. Links: zeigt alles Verfügbare, Reihenfolge zufällig, keine Schwellwerte, niemand löscht etwas. Rechts: zeigt, was eine Frage klärt, Reihenfolge folgt der Analyse, Schwellwerte mit Bedeutung, regelmäßig durchgesehen. Gehen Sie das für Ihr wichtigstes Dashboard durch. Die meisten Teams landen bei zwei bis drei Punkten links, und das ist normal — der Punkt ist nicht die Schuldzuweisung, sondern zu erkennen, dass ein Dashboard gepflegt werden will wie Code.

7:11 Diese Aufgabe ist bewusst provokant formuliert. Die Hälfte der Panels wird entfernt, und zu jeder Streichung notieren Sie, welche Frage dadurch nicht mehr beantwortet wird — oder dass es keine gab. Der Hinweis nennt den eigentlichen Ertrag: Panels, zu denen niemand eine Frage nennen kann, sind der Fund dieser Übung. In der Praxis ist das erfahrungsgemäß ein erheblicher Teil.

7:32 Und das ist kein Vorwurf an irgendjemanden — Dashboards wachsen, weil Hinzufügen einfach ist und Löschen sich nach Verlust anfühlt. Der erste Punkt verdient eine Erklärung: Gestapelte Flächen verdecken den Einbruch einer einzelnen Reihe, weil die Gesamthöhe gleich bleiben kann, während sich die Anteile verschieben. Das ist visuell überzeugend und sachlich irreführend. Der zweite ist der Aufwandsfehlschluss — ein Panel bleibt, weil es mühsam war, nicht weil es hilft.

8:00 Der dritte ist organisatorisch: Die Durchsicht findet nie statt, weil niemand zuständig ist; benennen Sie jemanden. Und der vierte sind ungekennzeichnete Testdashboards, die dauerhaft bleiben.

Übung

8:12 In der Übung bauen Sie das Service-Dashboard für den Annahmedienst — aus den Abfragen, die Sie in Modul dreizehn bereits geprüft haben. Danach wenden Sie die Antipattern-Liste auf ein absichtlich überladenes Beispiel an. Der zweite Teil ist erfahrungsgemäß der lehrreichere, weil er eine Fähigkeit übt, die im Alltag fehlt: begründet etwas wegzunehmen.

8:32 Fünf Kriterien, und sie fassen das ganze Modul zusammen: Rate, Fehlerquote und Latenzverteilung des Annahmedienstes; umschaltbar über eine Filialvariable; mit sinnvollen Einheiten und Schwellwerten; und mit Absprüngen in Trace und Log. Der Hinweis spart Ihnen Arbeit — übernehmen Sie die Abfragen aus Modul dreizehn unverändert. Sie sind geprüft, inklusive der richtigen Reihenfolge von rate und sum.

8:56 Neue Abfragen zu schreiben, wäre an dieser Stelle nur eine neue Gelegenheit für alte Fehler. Der rote Faden beginnt mit der Frage und endet bei der Navigation. Erst legen Sie fest, welche Frage das Dashboard beantwortet — schriftlich, das dauert zwei Minuten und verhindert die Bildergalerie. Dann die drei Abfragen als Panels, dann Einheiten, Beschriftungen und Schwellwerte. Dann die Variable, und zwar in allen Abfragen.

9:21 Und zuletzt die Absprünge, geprüft an einem echten Fall. Die Fußzeile nennt den zweiten Teil der Übung: das überladene Beispiel gegen die Antipattern-Liste halten und halbieren. Der erste Punkt ist die halb umgesetzte Variable von vorhin. Der zweite ist ein Vorgriff, der sich lohnt: Schwellwerte werden geraten, statt sie aus dem Ziel abzuleiten.

9:42 In Modul achtzehn definieren Sie ein Service Level Objective — und genau von dort sollte der Schwellwert kommen, nicht aus dem Bauch. Der dritte ist ein Rückfall hinter Modul vierzehn: Die Latenz erscheint als Mittelwert, obwohl das Histogramm längst vorliegt. Und der vierte deutet auf Modul neunzehn — ein geklicktes Dashboard lässt sich nicht in eine andere Umgebung übertragen.