Grafana-Datenquellen und Explore

Grafana-Datenquellen und Explore

0:00 Willkommen zu Tag drei. Heute geht es um das, was Menschen tatsächlich zu sehen bekommen: Oberfläche, Alarme, Ziele. Und wir fangen mit einer These an, die manche überraschen wird: Die erste Antwort entsteht nicht im Dashboard, sondern in Explore. Dashboards kommen später — oder in vielen Fällen gar nicht. Denn ein Dashboard beantwortet Fragen, die jemand vorher kannte. Störungen halten sich selten daran.

0:25 Wir schauen uns deshalb zuerst das Werkzeug für die freie Suche an.

Grafana-Datenquellen und Explore

0:30 Tag drei beschäftigt sich mit Grafana, Korrelation, Alarmierung und Zuverlässigkeitszielen. Dieses erste Modul richtet die Datenquellen ein und übt die Ad-hoc-Analyse: vom Symptom über den Trace zum Log, ohne ein einziges Dashboard. Und es schließt die Lücke, die uns seit Modul zwei begleitet — die Verbindung zwischen den Signalen. In der Übung grenzen Sie eine Störung allein mit freien Abfragen ein.

Datenquellen einrichten

0:54 Beginnen wir mit dem Handwerklichen. Drei Speicher, drei Abfragesprachen, eine Oberfläche — das ist die Ausgangslage seit Modul drei. Wie man die drei anbindet, ist schnell erzählt und in zehn Minuten erledigt. Interessanter ist die Frage, was man damit als Erstes tut, und die Antwort lautet in diesem Modul konsequent: nicht ein Dashboard bauen, sondern eine Frage stellen.

1:17 Eine Datenquelle beschreibt ein Backend samt Zugang und Abfrageweg. Für unsere Architektur sind es drei: Prometheus mit PromQL, Tempo mit TraceQL, Loki mit LogQL. Und dann der zentrale Begriff dieses Moduls: Explore ist der Ausgangspunkt zum Abfragen, Analysieren und Aggregieren dieser Daten. Die Dokumentation formuliert das sehr bewusst so — Explore ist nicht der Spielplatz für Fortgeschrittene, sondern der vorgesehene Startpunkt.

1:43 Alles, was später ein Dashboard wird, sollte hier entstanden und erprobt worden sein. Die dritte Spalte ist die interessante, denn sie zeigt die typische Abfolge einer Störungsanalyse. Bei Prometheus fragen Sie: Seit wann steigt die Fehlerquote? Bei Tempo: Welcher Vorgang war der langsamste? Bei Loki: Was meldete der Dienst zu diesem Vorgang? Die Fußzeile fasst es zusammen — erst die Metrik, dann der Trace, dann das Log.

2:10 Diese Reihenfolge ist kein Zufall: Sie gehen von der Gesamtheit zum Einzelfall zum Detail. Wer umgekehrt anfängt, also mit Logs, sucht in einem Heuhaufen ohne zu wissen, ob die Nadel darin liegt. Vier Argumente. Eine Abfrage lässt sich sofort erproben, ohne etwas anzulegen — das senkt die Hemmschwelle erheblich. Zeitbereich und Auflösung sind unmittelbar veränderbar, was bei der Suche nach dem richtigen Fenster hilft.

2:37 Der Query Inspector zeigt, was tatsächlich an das Backend ging; das ist das Diagnosewerkzeug für alle Fälle, in denen eine Abfrage anders wirkt als gedacht. Und der vierte Punkt ist die eigentliche Haltung: Erst was sich in Explore bewährt, lohnt den Weg ins Dashboard. Der erste Punkt ist unangenehm, weil er wie ein Datenproblem aussieht: Die Datenquelle ist erreichbar, zeigt aber auf den falschen Mandanten.

3:01 Der zweite ist der Klassiker schlechthin — der Zeitbereich steht auf einer Stunde, und die Störung lag gestern. Prüfen Sie das immer zuerst. Der dritte ist ein Betriebsrisiko: Eine zu feine Auflösung erzeugt so viele Punkte, dass die Abfrage den Server belastet. Und der vierte ist ein Vorgriff auf Modul neunzehn — von Hand angelegte Datenquellen existieren je Umgebung in unterschiedlichen Fassungen.

Ad-hoc-Analyse

3:25 Jetzt zur eigentlichen Arbeitstechnik. Eine Störungsanalyse besteht darin, sich von einer vagen Beobachtung zu einem konkreten Vorgang vorzuarbeiten — vom Symptom zur Ursache, über drei Datenquellen hinweg. Explore ist für genau diese Bewegung gebaut. Und die geteilte Ansicht ist dabei wichtiger, als ihr unscheinbarer Name vermuten lässt.

3:46 In Explore lassen sich Abfragen unmittelbar formulieren und nebeneinander stellen. Die geteilte Ansicht zeigt zwei Abfragen gleichzeitig — etwa eine Metrik links und die passenden Logs rechts. Und die Abfragehistorie hält fest, was bereits versucht wurde. Dieser letzte Punkt wird oft übersehen und ist im Ernstfall wertvoll: Wenn drei Leute gleichzeitig an einer Störung arbeiten, verhindert die Historie, dass alle dasselbe dreimal probieren.

4:11 Diese vier Stationen sind die Standardroute, und Sie werden sie in jedem Störungsfall wiedererkennen. Die Metrik ist auffällig — irgendetwas stimmt nicht. Der Trace ist gefunden — dieser eine Vorgang war betroffen. Der Dienst ist bestimmt — hier ist die Zeit verloren gegangen. Das Log ist gelesen — das war der Grund. Jeder Übergang zwischen diesen Stationen kostet ohne Vorbereitung Minuten und mit Vorbereitung Sekunden. Genau diese Vorbereitung ist das Thema des dritten Kapitels.

4:41 Vier Gründe. Metrik und Log nebeneinander beantworten die Frage nach dem Zusammenhang — passt der Fehlertext zeitlich zum Ausschlag? Der Zeitbereich bleibt für beide Seiten derselbe und verhindert Trugschlüsse; das ist wichtiger, als es klingt, weil zwei Fenster mit verschiedenen Zeiträumen sehr überzeugend falsche Zusammenhänge nahelegen.

5:00 Die Historie macht den Analyseweg für andere nachvollziehbar. Und was sich bewährt, wandert später unverändert ins Dashboard — also nicht neu gebaut, sondern übernommen. Der erste Punkt ist der verbreitetste Anfängerreflex: Die Analyse beginnt im Dashboard, das die entscheidende Kennzahl gar nicht zeigt — und endet damit sofort.

5:20 Der zweite sind unterschiedliche Zeitbereiche in den beiden Hälften. Der dritte ist eine Abkürzung, die keine ist: Die Suche nach dem Trace über die Uhrzeit statt über die Trace-ID; damit finden Sie irgendeinen Vorgang, nicht Ihren. Und der vierte ist Wissensverlust — der gefundene Weg wird nicht notiert und beim nächsten Mal neu gesucht.

Verbindungen zwischen Datenquellen

5:40 Kommen wir zu dem Teil, der die drei getrennten Speicher zu einem System macht. Ohne diese Verbindungen haben Sie drei Werkzeuge nebeneinander und kopieren Kennungen von Hand hin und her. Mit ihnen haben Sie einen durchgehenden Analyseweg. Der Unterschied kostet im Ruhezustand nichts und ist im Störfall der Unterschied zwischen zehn Minuten und einer Stunde.

6:00 Eine Correlation legt fest, wie ein Wert aus einer Datenquelle eine Abfrage in einer anderen auslöst oder eine externe Adresse bildet. Sie erscheint als anklickbarer Verweis in Explore — in Logzeilen und in Tabellenzellen. Das ist technisch unspektakulär und praktisch der größte Zeitgewinn dieses Moduls. Dazu kommen Annotations: Sie markieren Zeitpunkte wie Releases oder Wartungsfenster direkt im Diagramm. Damit beantwortet sich die häufigste Rückfrage bei jeder Störung von selbst.

6:30 Drei Verbindungen, die sich in praktisch jeder Umgebung lohnen. Von einer Logzeile mit Trace-ID zum Trace — das ist die Verbindung, die Sie am häufigsten benutzen werden. Vom Trace zur Metrik des betroffenen Dienstes, um zu klären, ob es ein Einzelfall ist. Und von einer Metrikspitze über das Exemplar zum Trace, also genau der Weg aus Modul vierzehn.

6:51 Die Fußzeile nennt noch die Annotations, und die verdienen eine Erwähnung, weil sie die häufigste Rückfrage im Störfall beantworten: Lag es an einem Release? Der erste Punkt beschreibt den Alltag in vielen Teams: Trace-IDs werden aus Logzeilen kopiert und in Suchfelder eingefügt. Das funktioniert, ist aber fehleranfällig und kostet jedes Mal dieselbe Minute.

7:13 Der zweite Punkt ist subtiler — jeder Werkzeugwechsel bricht den Gedankengang; wer mitten in einer Analyse steckt, verliert dabei Kontext. Der dritte ist ökonomisch: einmal einrichten, für alle nutzbar. Und der vierte deutet auf Modul neunzehn — auch Correlations lassen sich als Konfiguration bereitstellen und damit versionieren.

7:33 Sie richten jetzt die wichtigste der drei Verbindungen ein. Erfolgskriterium: Ein Klick in einer Logzeile von Pfandwerk öffnet den zugehörigen Trace. Und der Hinweis ist ein Rat aus der Praxis: Prüfen Sie das an einem Fehlerfall, nicht am Normalfall. Denn genau dort fehlt die Trace-ID am ehesten — etwa weil eine Ausnahme außerhalb des instrumentierten Bereichs protokolliert wurde.

7:55 Eine Correlation, die nur im Gutfall funktioniert, hilft Ihnen nie, weil Sie sie nur im Schlechtfall brauchen. Der erste Punkt ist die Voraussetzung, die gern fehlt: Die Verbindung ist eingerichtet, aber die Logzeilen tragen keine Trace-ID. Dann müssen Sie zurück zu Modul sechs. Der zweite ist eine Halblösung — der Verweis führt auf ein Zeitfenster statt auf den konkreten Trace, und Sie suchen wieder.

8:20 Der dritte ist ein Verteilungsproblem: Die Correlation existiert nur in der Testumgebung. Und der vierte betrifft die Annotations — sie werden von Hand gesetzt und bleiben nach zwei Wochen aus. Automatisieren Sie das aus Ihrer Bereitstellungskette heraus.

Übung

8:35 In der Übung grenzen Sie eine Störung ohne Dashboard ein. Diese Einschränkung ist der Zweck der Übung: Sie zwingt Sie, die Werkzeuge zu benutzen, die im echten Störfall tatsächlich helfen. Denn im Ernstfall zeigt das vorhandene Dashboard erfahrungsgemäß genau die Kennzahl nicht, um die es gerade geht — und dann beginnt die Arbeit in Explore.

8:55 Das Ziel: Der verursachende Dienst ist benannt und belegt — durch eine Metrik, einen Trace und die zugehörige Logzeile. Und der Absprung vom Log zum Trace funktioniert. Der Hinweis ist die eigentliche Regel dieser Übung: kein Dashboard anlegen. Ich weiß, dass die Versuchung groß ist. Aber wer im Störfall erst ein Dashboard baut, hat die Störung noch nicht verstanden — und baut deshalb meistens das falsche.

9:20 Der rote Faden ist die Route aus Kapitel zwei, diesmal konkret. Datenquellen einrichten und je eine Probeabfrage stellen — das erspart die Verwechslung von Konfigurationsfehler und Datenproblem. Dann die auffällige Metrik suchen und den Zeitbereich eingrenzen. Dann über das Exemplar oder die Suche einen Trace öffnen. Dann den langsamsten Span bestimmen — das ist der verursachende Dienst. Und zuletzt die Correlation einrichten und prüfen.

9:47 Die Fußzeile verrät, wohin das führt: Dieser Weg ist die Vorlage für das Diagnose-Dashboard in Modul sechzehn. Der erste Punkt ist eine menschliche Schwäche, die in Störungen viel Zeit kostet: Die Ursache wird geraten, und danach sucht man eine Abfrage, die es bestätigt. Der zweite ist ein handwerklicher Fehler im Trace — der langsamste Span wird mit dem äußersten verwechselt.

10:10 Der äußerste Span dauert immer am längsten, er enthält ja alle anderen; interessant ist der, der die meiste eigene Zeit verbraucht. Der dritte ist eine unscharfe Filterung über den Dienstnamen statt der Trace-ID. Und der vierte: Der Analyseweg wird nicht festgehalten und ist morgen vergessen.